LVI: Hijacking Transient Execution Through Microarchitectural Load Value Injection

Total Page:16

File Type:pdf, Size:1020Kb

LVI: Hijacking Transient Execution Through Microarchitectural Load Value Injection LVI: Hijacking Transient Execution through Microarchitectural Load Value Injection Jo Van Bulck∗, Daniel Moghimiy, Michael Schwarzz, Moritz Lippz, Marina Minkinx, Daniel Genkinx, Yuval Yarom{, Berk Sunary, Daniel Grussz, and Frank Piessens∗ ∗imec-DistriNet, KU Leuven yWorcester Polytechnic Institute zGraz University of Technology xUniversity of Michigan {University of Adelaide and Data61 Abstract—The recent Spectre attack first showed how to inject operations, which may encode the data before an exception incorrect branch targets into a victim domain by poisoning is eventually raised. Over the past year, delayed exception microarchitectural branch prediction history. In this paper, we handling and microcode assists have been shown to transiently generalize injection-based methodologies to the memory hierar- chy by directly injecting incorrect, attacker-controlled values into expose data from various microarchitectural elements (i.e., L1D a victim’s transient execution. We propose Load Value Injection cache [42, 61], FPU register file [57], line-fill buffer [42, 53, (LVI) as an innovative technique to reversely exploit Meltdown- 67], store buffer [9], and load ports [29, 67]). Unlike Spectre- type microarchitectural data leakage. LVI abuses that faulting type attacks, a Meltdown attacker in one security domain can or assisted loads, executed by a legitimate victim program, may directly exfiltrate architecturally inaccessible data belonging to transiently use dummy values or poisoned data from various microarchitectural buffers, before eventually being re-issued by another domain (e.g., kernel memory). Consequently, existing the processor. We show how LVI gadgets allow to expose Meltdown mitigations focus on restricting the attacker’s point victim secrets and hijack transient control flow. We practically of view, e.g., placing victim data out of reach [20], flushing demonstrate LVI in several proof-of-concept attacks against Intel buffers after victim execution [25, 29], or zeroing unauthorized SGX enclaves, and we discuss implications for traditional user data flow directly at the silicon level [28]. process and kernel isolation. State-of-the-art Meltdown and Spectre defenses, including Given the widespread deployment of Meltdown countermea- widespread silicon-level and microcode mitigations, are orthog- sures, including changes in operating systems and CPUs, we onal to our novel LVI techniques. LVI drastically widens the ask the following fundamental questions in this paper: spectrum of incorrect transient paths. Fully mitigating our attacks requires serializing the processor pipeline with lfence Can Meltdown-type effects only be used for leakage or also instructions after possibly every memory load. Additionally and for injection? Would current hardware and software defenses even worse, due to implicit loads, certain instructions have to suffice to fully eradicate Meltdown-type threats based on illegal be blacklisted, including the ubiquitous x86 ret instruction. data flow from faulting or assisted instructions? Intel plans compiler and assembler-based full mitigations that will allow at least SGX enclave programs to remain secure A. Our Results and Contributions on LVI-vulnerable systems. Depending on the application and In this paper, we introduce an innovative class of Load optimization strategy, we observe extensive overheads of factor 2 to 19 for prototype implementations of the full mitigation. Value Injection (LVI) attack techniques. Our key contribution is to recognize that, under certain adversarial conditions, I. INTRODUCTION unintended microarchitectural leakage can also be inverted Recent research on transient-execution attacks has been to inject incorrect data into the victim’s transient execution. characterized by a sharp split between on the one hand Spectre- Being essentially a “reverse Meltdown”-type attack, LVI abuses type misspeculation attacks, and on the other hand, Meltdown- that a faulting or assisted load instruction executed within a type data extraction attacks. The first category, Spectre-type victim domain does not always yield the expected result, but attacks [4, 23, 38, 39, 44], trick a victim into transiently may instead transiently forward dummy values or (attacker- diverting from its intended execution path. Particularly, by controlled) data from various microarchitectural buffers. We poisoning the processor’s branch predictor machinery, Spectre consider attackers that can either directly or indirectly induce adversaries steer the victim’s transient execution to gadget code page faults or microcode assists during victim execution. LVI snippets, which inadvertently expose secrets through the shared provides such attackers with a primitive to force a legitimate microarchitectural state. Importantly, Spectre gadgets execute victim execution to transiently compute on “poisoned” data entirely within the victim domain and can hence only leak (e.g., pointers, array indices) before the CPU eventually detects architecturally accessible data. the fault condition and discards the pending architectural The second category consists of Meltdown-type attacks [9, state changes. Much like in Spectre attacks, LVI relies on 42, 53, 57, 61, 67, 70], which target architecturally inaccessible “confused deputy” code gadgets surrounding the faulting or data by exploiting illegal data flow from faulting or assisted assisted load in the victim to hijack transient control flow and instructions. Particularly, on vulnerable processors, the results disclose information. We are the first to combine Meltdown- of unauthorized loads are still forwarded to subsequent transient style microarchitectural data leakage with Spectre-style code TABLE I. Characterization of known side-channel and transient-execution contrast to prior Spectre-type effects that are contained around attacks in terms of targeted microarchitectural predictor or data buffer (vertical clear-cut (branch) misprediction locations. axis) vs. leakage- or injection-based methodology (horizontal axis). The LVI attack plane, first explored in this paper, is indicated on the lower right and Successfully exploiting LVI requires the ability to induce applies an injection-based methodology known from Spectre attacks (upper page faults or microcode assists during victim execution. We right) to reversely exploit Meltdown-type data leakage (lower left). show that this requirement can be most easily met in Intel SGX environments, where we develop several proof-of-concept Methodology Leakage Injection attacks that abuse dangerous real-world gadgets to arbitrarily µ-Arch Buffer divert transient control flow in the enclave. We furthermore PHT BranchScope [15], Bluethunder [24] Spectre-PHT [38] BTB SBPA [1], BranchShadow [40] Spectre-BTB [38] mount a novel transient fault attack on AES-NI to extract full RSB Hyper-Channel [8] Spectre-RSB [39, 44] cryptographic keys from a victim enclave. While LVI attacks history STL — Spectre-STL [23] Prediction in non-SGX environments are generally much harder to mount, L1D Meltdown [42] LVI-NULL we consider none of the adversarial conditions for LVI to be L1D Foreshadow [61] LVI-L1D unique to Intel SGX. We explore consequences for traditional FPU LazyFP [57] LVI-FPU SB Fallout [9] LVI-SB process isolation by showing that, given a suitable LVI gadget Program data LFB/LP ZombieLoad [53], RIDL [67] LVI-LFB/LP and a faulting or assisted load in the kernel, arbitrary supervisor memory may leak to user space. We also show that the same vector could be exploited in a cross-process LVI attack. gadget abuse to compose a novel type of transient load value Underlining the impact and the practical challenges arising injection attacks. from our findings, Intel plans to mitigate LVI by extensive TableI summarizes how Spectre [ 38] first applied an revisions at the compiler and assembler levels to allow at injection-based methodology to invert prior branch prediction least compilation of SGX enclaves to remain secure on LVI- side-channel attacks, whereas LVI similarly shows that recent vulnerable systems. Particularly, fully mitigating LVI requires Meltdown-type microarchitectural data leakage can be reversely introducing lfence instructions to serialize the processor exploited. Looking at TableI, it becomes apparent that Spectre- pipeline after possibly every memory load operation. Addi- style injection attacks have so far only been applied to auxiliary tionally, certain instructions featuring implicit loads, including history-based branch prediction and dependency prediction the pervasive x86 ret instruction, should be blacklisted and buffers that accumulate program metadata to steer the victim’s emulated with equivalent serialized instruction sequences. We transient execution indirectly. Our techniques, on the other observe extensive performance overheads of factor 2 to 19 for hand, intervene much more directly in the victim’s transient our evaluation of prototype compiler mitigations, depending data stream by injecting erroneous load values straight from on the application and whether lfences were inserted by an the CPU’s memory hierarchy, i.e., intermediate load and store optimized compiler pass or through a naive post-compilation buffers and caches. assembler approach. These fundamentally different microarchitectural behaviors In summary, our main contributions are as follows: (i.e., misprediction vs. illegal data flow) also entail that LVI • We show that Meltdown-type data leakage can be inverted requires defenses that are orthogonal and complementary to into
Recommended publications
  • SPP 2019.09.0 Component Release Notes
    SPP 2019.09.0 Component Release Notes BIOS - System ROM Driver - Chipset Driver - Network Driver - Storage Driver - Storage Controller Driver - Storage Fibre Channel and Fibre Channel Over Ethernet Driver - System Driver - System Management Driver - Video Firmware - Blade Infrastructure Firmware - Lights-Out Management Firmware - Network Firmware - NVDIMM Firmware - PCIe NVMe Storage Disk Firmware - Power Management Firmware - SAS Storage Disk Firmware - SATA Storage Disk Firmware - Storage Controller Firmware - Storage Fibre Channel Firmware - System Firmware (Entitlement Required) - Storage Controller Software - Lights-Out Management Software - Management Software - Network Software - Storage Controller Software - Storage Fibre Channel Software - Storage Fibre Channel HBA Software - System Management BIOS - System ROM Top Online ROM Flash Component for Linux - HPE ProLiant DL380 Gen9/DL360 Gen9 (P89) Servers Version: 2.74_07-21-2019 (Optional) Filename: RPMS/i386/firmware-system-p89-2.74_2019_07_21-1.1.i386.rpm Important Note! Important Notes: None Deliverable Name: HPE ProLiant DL360/DL380 Gen9 System ROM - P89 Release Version: 2.74_07-21-2019 Last Recommended or Critical Revision: 2.72_03-25-2019 Previous Revision: 2.72_03-25-2019 Firmware Dependencies: None Enhancements/New Features: This revision of the System ROM includes the latest revision of the Intel microcode which provides mitigation for an Intel sighting where the system may experience a machine check after updating to the latest System ROM which contained a fix for an Intel TSX (Transactional Synchronizations Extensions) sightings. The previous microcode was first introduced in the v2.70 System ROM. This issue only impacts systems configured with Intel Xeon v4 Series processors. This issue is not unique to HPE servers. Problems Fixed: Addressed an extremely rare issue where a system booting to VMware may experience a PSOD in legacy boot mode.
    [Show full text]
  • Microcode Revision Guidance August 31, 2019 MCU Recommendations
    microcode revision guidance August 31, 2019 MCU Recommendations Section 1 – Planned microcode updates • Provides details on Intel microcode updates currently planned or available and corresponding to Intel-SA-00233 published June 18, 2019. • Changes from prior revision(s) will be highlighted in yellow. Section 2 – No planned microcode updates • Products for which Intel does not plan to release microcode updates. This includes products previously identified as such. LEGEND: Production Status: • Planned – Intel is planning on releasing a MCU at a future date. • Beta – Intel has released this production signed MCU under NDA for all customers to validate. • Production – Intel has completed all validation and is authorizing customers to use this MCU in a production environment.
    [Show full text]
  • SDG Adhoc Reporting
    VMware Deliverable Release Notes This document does not apply to HPE Superdome servers. For information on HPE Superdome, see the following links: HPE Integrity Superdome X HPE Superdome Flex Information on HPE Synergy supported VMware ESXi OS releases, HPE ESXi Custom Images and HPE Synergy Custom SPPs is available at: VMware OS Support Tool for HPE Synergy Information on HPE Synergy Software Releases is available at: HPE Synergy Software Releases - Overview SPP 2021.04.0 Release Notes for VMware vSphere 6.5 BIOS (Login Required) - System ROM Driver - Network Driver - Storage Controller Firmware - Network Firmware - NVDIMM Firmware - Storage Controller Firmware - Storage Fibre Channel Software - Management Software - Storage Controller Software - Storage Fibre Channel Software - System Management BIOS (Login Required) - System ROM Top ROM Flash Firmware Package - HPE Apollo 2000 Gen10/HPE ProLiant XL170r/XL190r Gen10 (U38) Servers Version: 2.42_01-23-2021 (Recommended) Filename: U38_2.42_01_23_2021.fwpkg Important Note! Important Notes: None Deliverable Name: HPE Apollo 2000 Gen10/HPE ProLiant XL170r/XL190r Gen10 System ROM - U38 Release Version: 2.42_01-23-2021 Last Recommended or Critical Revision: 2.42_01-23-2021 Previous Revision: 2.40_10-26-2020 Firmware Dependencies: None Enhancements/New Features: Updated the support for Fast Fault Tolerant Memory Mode (ADDDC) to improve system uptime. Added support to the BIOS/Platform Configuration (RBSU) Time Zones to add Dublin/London (UTC+1). This support also requires the latest version of iLO Firmware, version 2.40 or later. Problems Fixed: This revision of the System ROM includes the latest revision of the Intel microcode which provides a fix for a potential machine check exception under heavy stress with short loops of instructions.
    [Show full text]
  • Efficiently Mitigating Transient Execution Attacks Using the Unmapped Speculation Contract Jonathan Behrens, Anton Cao, Cel Skeggs, Adam Belay, M
    Efficiently Mitigating Transient Execution Attacks using the Unmapped Speculation Contract Jonathan Behrens, Anton Cao, Cel Skeggs, Adam Belay, M. Frans Kaashoek, and Nickolai Zeldovich, MIT CSAIL https://www.usenix.org/conference/osdi20/presentation/behrens This paper is included in the Proceedings of the 14th USENIX Symposium on Operating Systems Design and Implementation November 4–6, 2020 978-1-939133-19-9 Open access to the Proceedings of the 14th USENIX Symposium on Operating Systems Design and Implementation is sponsored by USENIX Efficiently Mitigating Transient Execution Attacks using the Unmapped Speculation Contract Jonathan Behrens, Anton Cao, Cel Skeggs, Adam Belay, M. Frans Kaashoek, and Nickolai Zeldovich MIT CSAIL Abstract designers have implemented a range of mitigations to defeat transient execution attacks, including state flushing, selectively Today’s kernels pay a performance penalty for mitigations— preventing speculative execution, and removing observation such as KPTI, retpoline, return stack stuffing, speculation channels [5]. These mitigations impose performance over- barriers—to protect against transient execution side-channel heads (see §2): some of the mitigations must be applied at attacks such as Meltdown [21] and Spectre [16]. each privilege mode transition (e.g., system call entry and exit), To address this performance penalty, this paper articulates and some must be applied to all running code (e.g., retpolines the unmapped speculation contract, an observation that mem- for all indirect jumps). In some cases, they are so expensive ory that isn’t mapped in a page table cannot be leaked through that OS vendors have decided to leave them disabled by de- transient execution. To demonstrate the value of this contract, fault [2, 22].
    [Show full text]
  • Class-Action Lawsuit
    Case 3:20-cv-00863-SI Document 1 Filed 05/29/20 Page 1 of 279 Steve D. Larson, OSB No. 863540 Email: [email protected] Jennifer S. Wagner, OSB No. 024470 Email: [email protected] STOLL STOLL BERNE LOKTING & SHLACHTER P.C. 209 SW Oak Street, Suite 500 Portland, Oregon 97204 Telephone: (503) 227-1600 Attorneys for Plaintiffs [Additional Counsel Listed on Signature Page.] UNITED STATES DISTRICT COURT DISTRICT OF OREGON PORTLAND DIVISION BLUE PEAK HOSTING, LLC, PAMELA Case No. GREEN, TITI RICAFORT, MARGARITE SIMPSON, and MICHAEL NELSON, on behalf of CLASS ACTION ALLEGATION themselves and all others similarly situated, COMPLAINT Plaintiffs, DEMAND FOR JURY TRIAL v. INTEL CORPORATION, a Delaware corporation, Defendant. CLASS ACTION ALLEGATION COMPLAINT Case 3:20-cv-00863-SI Document 1 Filed 05/29/20 Page 2 of 279 Plaintiffs Blue Peak Hosting, LLC, Pamela Green, Titi Ricafort, Margarite Sampson, and Michael Nelson, individually and on behalf of the members of the Class defined below, allege the following against Defendant Intel Corporation (“Intel” or “the Company”), based upon personal knowledge with respect to themselves and on information and belief derived from, among other things, the investigation of counsel and review of public documents as to all other matters. INTRODUCTION 1. Despite Intel’s intentional concealment of specific design choices that it long knew rendered its central processing units (“CPUs” or “processors”) unsecure, it was only in January 2018 that it was first revealed to the public that Intel’s CPUs have significant security vulnerabilities that gave unauthorized program instructions access to protected data. 2. A CPU is the “brain” in every computer and mobile device and processes all of the essential applications, including the handling of confidential information such as passwords and encryption keys.
    [Show full text]
  • NEC V. Intel: a Guide to Using "Clean Room" Procedures As Evidence, 10 Computer L.J
    The John Marshall Journal of Information Technology & Privacy Law Volume 10 Issue 4 Computer/Law Journal - Winter 1990 Article 1 Winter 1990 NEC v. Intel: A Guide to Using "Clean Room" Procedures as Evidence, 10 Computer L.J. 453 (1990) David S. Elkins Follow this and additional works at: https://repository.law.uic.edu/jitpl Part of the Computer Law Commons, Internet Law Commons, Privacy Law Commons, and the Science and Technology Law Commons Recommended Citation David S. Elkins, NEC v. Intel: A Guide to Using "Clean Room" Procedures as Evidence, 10 Computer L.J. 453 (1990) https://repository.law.uic.edu/jitpl/vol10/iss4/1 This Article is brought to you for free and open access by UIC Law Open Access Repository. It has been accepted for inclusion in The John Marshall Journal of Information Technology & Privacy Law by an authorized administrator of UIC Law Open Access Repository. For more information, please contact [email protected]. NEC V. INTEL: A GUIDE TO USING "CLEAN ROOM" PROCEDURES AS EVIDENCE DAVID S. ELKINS* I. INTRODUCTION The recent United States District Court decision in NEC Corp. v. Intel Corp.' has made a significant imprint on the field of copyright law in two respects. The case marks the first time that computer microcode 2 has been held copyrightable,3 and the first time that "clean room" procedures have been used as evidence in an infringement ac- tion.4 Simply put, clean room procedures comprise a method of creating a certain type of technology without the possibility of influence from outside sources. These procedures may be necessary in situations where the mere creation of the technology gives rise to an inference of copy- * J.D., King Hall School of Law, University of California, Davis, 1990; A.B., Univer- sity of California, Berkeley, 1986.
    [Show full text]
  • Accelerate Hybrid Cloud AI Workloads Solution Brief
    Solution Brief Data Center | Hybrid Cloud Accelerate Hybrid Cloud AI Workloads Ease your journey to hybrid/multicloud with a reference architecture for Intel® technology and VMware Cloud Foundation Executive Summary To remain competitive in today’s world, organizations need a modern data center. Companies using these data centers must accelerate their product development, compete more successfully at a lower cost, and Solution Benefits reduce their downtime and maintenance overhead. Technology must move and change with the times—solutions for hosting applications and Intel’s VMware Cloud Foundation services must innovate and change as well. reference architecture takes advantage of Intel® compute, Companies with older and outdated data centers will want to meet these memory, storage, and networking challenges by upgrading to hybrid cloud solutions, where the data center innovations to help enable can easily and seamlessly interface between on‑premises and cloud software-defined data centers and systems. Based on VMware Cloud Foundation with VMware Tanzu, Intel hybrid/multicloudOptional adoption. partner logo goes here addressed these requirements by offering a hybrid/multicloud reference • Fast AI inference. AI workloads architecture—available in a Base and Plus configuration—that is easily can benefit from innovations deployable and manageable for virtual machines (VMs) and containers. from Intel such as Intel® DL Boost. • Flexibility and portability. VMware Cloud Foundation helps enable enterprises to run their workloads where it makes most sense, whether that’s Private Public on‑premises, in a public cloud, Cloud Cloud or in several clouds at once. VMware Cloud Foundation VMware VMware VMware VMware vSphere vRealize Suite vSA S‑T VMware SDDC Manager Figure 1.
    [Show full text]
  • Beyond MOV ADD XOR – the Unusual and Unexpected
    Beyond MOV ADD XOR the unusual and unexpected in x86 Mateusz "j00ru" Jurczyk, Gynvael Coldwind CONFidence 2013, Kraków Who • Mateusz Jurczyk o Information Security Engineer @ Google o http://j00ru.vexillium.org/ o @j00ru • Gynvael Coldwind o Information Security Engineer @ Google o http://gynvael.coldwind.pl/ o @gynvael Agenda • Getting you up to speed with new x86 research. • Highlighting interesting facts and tricks. • Both x86 and x86-64 discussed. Security relevance • Local vulnerabilities in CPU ↔ OS integration. • Subtle CPU-specific information disclosure. • Exploit mitigations on CPU level. • Loosely related considerations and quirks. x86 - introduction not required • Intel first ships 8086 in 1978 o 16-bit extension of the 8-bit 8085. • Only 80386 and later are used today. o first shipped in 1985 o fully 32-bit architecture o designed with security in mind . code and i/o privilege levels . memory protection . segmentation x86 - produced by... Intel, AMD, VIA - yeah, we all know these. • Chips and Technologies - left market after failed 386 compatible chip failed to boot the Windows operating system. • NEC - sold early Intel architecture compatibles such as NEC V20 and NEC V30; product line transitioned to NEC internal architecture http://www.cpu-collection.de/ x86 - other manufacturers Eastern Bloc KM1810BM86 (USSR) http://www.cpu-collection.de/ x86 - other manufacturers Transmeta, Rise Technology, IDT, National Semiconductor, Cyrix, NexGen, Chips and Technologies, IBM, UMC, DM&P Electronics, ZF Micro, Zet IA-32, RDC Semiconductors, Nvidia, ALi, SiS, GlobalFoundries, TSMC, Fujitsu, SGS-Thomson, Texas Instruments, ... (via Wikipedia) At first, a simple architecture... At first, a simple architecture... x86 bursted with new functions • No eXecute bit (W^X, DEP) o completely redefined exploit development, together with ASLR • Supervisor Mode Execution Prevention • RDRAND instruction o cryptographically secure prng • Related: TPM, VT-d, IOMMU Overall..
    [Show full text]
  • SDG Adhoc Reporting
    VMware Deliverable Release Notes This document does not apply to HPE Superdome servers. For information on HPE Superdome, see the following links: HPE Integrity Superdome X HPE Superdome Flex Information on HPE Synergy supported VMware ESXi OS releases, HPE ESXi Custom Images and HPE Synergy Custom SPPs is available at: VMware OS Support Tool for HPE Synergy Information on HPE Synergy Software Releases is available at: HPE Synergy Software Releases - Overview VMware Upgrade Pack v1.4.2.1 Release Notes for VMware ESXi 7.0 U2 BIOS (Login Required) - System ROM Driver - Lights-Out Management Driver - Network Driver - Storage Controller Driver - System Management Firmware - Network Firmware - NVDIMM Firmware - Storage Controller Firmware - Storage Fibre Channel Software - Management Software - Storage Fibre Channel Software - System Management BIOS (Login Required) - System ROM Top ROM Flash Firmware Package - HPE Apollo 2000 Gen10/HPE ProLiant XL170r/XL190r Gen10 (U38) Servers Version: 2.42_01-23-2021 (Recommended) Filename: U38_2.42_01_23_2021.fwpkg Important Note! Important Notes: None Deliverable Name: HPE Apollo 2000 Gen10/HPE ProLiant XL170r/XL190r Gen10 System ROM - U38 Release Version: 2.42_01-23-2021 Last Recommended or Critical Revision: 2.42_01-23-2021 Previous Revision: 2.40_10-26-2020 Firmware Dependencies: None Enhancements/New Features: Updated the support for Fast Fault Tolerant Memory Mode (ADDDC) to improve system uptime. Added support to the BIOS/Platform Configuration (RBSU) Time Zones to add Dublin/London (UTC+1). This support also requires the latest version of iLO Firmware, version 2.40 or later. Problems Fixed: This revision of the System ROM includes the latest revision of the Intel microcode which provides a fix for a potential machine check exception under heavy stress with short loops of instructions.
    [Show full text]
  • LVI-LFB: Scenarios 3 & 4
    WHITEPAPER Security Load Value Injection in the Line Fill Buffers: How to Hijack Control Flow without Spectre www.bitdefender.com Contents Abstract .............................................................................................................................3 Introduction .......................................................................................................................3 Recap – Meltdown, Spectre & MDS .................................................................................4 Meltdown .................................................................................................................................4 Spectre ..................................................................................................................................... 4 Microarchitectural Data Sampling .......................................................................................... 5 Load Value Injection in the Line Fill Buffers ....................................................................5 Exploiting LVI-LFB: scenarios 3 & 4..................................................................................7 Real-life exploit ..................................................................................................................7 Mitigations .........................................................................................................................8 Conclusions .......................................................................................................................9
    [Show full text]
  • Introduction
    Volume 3, Spring Issue, 1990 NEC v. INTEL : BREAKING NEW GROUND IN THE LAW OF COPYRIGHT Jorge Contreras,* Laura Handley,* and Terrence Yang* INTRODUCTION The status of copyright protection for computer programs has long been in a state of confusion. In NEC Corp. v. Intel Corp., 1 the U.S. Dis- trict Court for the Northern District of California shed some light on three previously unresolved issues in this murky and continually evolv- ing area of copyright. The court ruled that: (1) microcode embedded in certain Intel microprocessors constituted copyrightable material; (2) reverse engineering of the microcode did not infringe the microcode copyright; and (3)independent "clean room" development of similar microcode was persuasive evidence of non-infringement. The execution of a computer program within a computer involves a number of different, operational levels. 2 An applications programmer may write a program to'solve a problem in a high-level.problem-oriented language containing familiar words, variables, and operators. Examples of high-level languages include BASIC, C, FORTRAN, COBOL, and Pascal. However, high-level languages cannot be implemented as such by a computer, which is controlled by the operation of digital circuits. Before instructions can be executed, a program must undergo a series of transformations that enable it-to operate the computer's digital circuitry. The first step in this transformation may involve translation of the pro- gram by a compiler into an assembly-level program. Assembly languages generally reflect the internal organization and operation of the computer more than higher-level languages do, but are still incapable of directly controlling the computer.
    [Show full text]
  • Software-Based Power Side-Channel Attacks on X86
    PLATYPUS: Software-based Power Side-Channel Attacks on x86 Moritz Lipp∗, Andreas Kogler∗, David Oswald†, Michael Schwarz‡, Catherine Easdon∗, Claudio Canella∗, and Daniel Gruss∗ ∗ Graz University of Technology †University of Birmingham, UK ‡CISPA Helmholtz Center for Information Security Abstract—Power side-channel attacks exploit variations in on an ARM TrustZone-M platform using an onboard ADC, power consumption to extract secrets from a device, e.g., crypto- and Mantel et al. [56] distinguished different RSA keys by graphic keys. Prior attacks typically required physical access to measuring the power consumption on Intel desktop machines. the target device and specialized equipment such as probes and a high-resolution oscilloscope. The experimental results of Mantel et al. on RSA demonstrated In this paper, we present PLATYPUS attacks, which are that certain multiply operations of the square-and-multiply novel software-based power side-channel attacks on Intel server, implementation can be detected, but no full key recovery was desktop, and laptop CPUs. We exploit unprivileged access to achieved. Similarly, Fusi [20] tried to recover RSA-16384 keys the Intel Running Average Power Limit (RAPL) interface that but concluded that the sampling rate of the interface is too low exposes values directly correlated with power consumption, forming a low-resolution side channel. to mount an attack. We show that with sufficient statistical evaluation, we can In this work, we present PLATYPUS1 attacks which are observe variations in power consumption, which distinguish novel software-based power side-channel attacks on Intel different instructions and different Hamming weights of operands servers, desktops, and laptops by abusing unprivileged access and memory loads.
    [Show full text]