DOCSLIB.ORG

Breaking Virtual Memory Protection and the SGX Ecosystem with Foreshadow

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Breaking Virtual Memory Protection and the SGX Ecosystem with Foreshadow Top Picks Breaking Virtual Memory Protection and the SGX Ecosystem with Foreshadow Jo Van Bulck Frank Piessens Katholieke Universiteit Leuven Katholieke Universiteit Leuven Marina Minkin Mark Silberstein University of Michigan Technion–Israel Institute of Technology Ofir Weisse Thomas F. Wenisch University of Michigan University of Michigan Daniel Genkin Yuval Yarom University of Michigan University of Adelaide and Data61, CSIRO Baris Kasikci Raoul Strackx University of Michigan Katholieke Universiteit Leuven Abstract—Foreshadow is a speculative execution attack that allows adversaries to subvert the security guarantees of Intel’s Software Guard eXtensions (SGX). Foreshadow allows access to data across process boundaries, and allows virtual machines (VMs) to read the physical memory belonging to other VMs or the hypervisor. & OVER THE PAST year and a half, speculative have gone from a hypothetical possibility to a execution attacks-–attacks that subvert memory very real threat.1,2 These attacks allow software to protection by exploiting the speculative execution exploit microarchitectural flaws, wherein specula- features of modern out-of-order processors— tive wrong-path instructions are allowed to access memory in violation of architectural protection guarantees. For example, the Meltdown flaw2 Digital Object Identifier 10.1109/MM.2019.2910104 allows the user-level code to access kernel Date of publication 15 April 2019; date of current version 8 memory locations that are mapped into the pro- May 2019. cess address space but are restricted to privileged 66 0272-1732 ß 2019 IEEE Published by the IEEE Computer Society IEEE Micro accesses only. Speculative execution attacks that data accessed during execution cannot be exploit the transient data access of wrong-path observed by the privileged cloud vendor. instructions by leaking secret data into a side chan- To support such private and secure code exe- nel. Side-channel attacks exploit subtle timing var- cution, SGX provides isolated execution environ- iations in program execution resulting from state ments, called enclaves, which offer confidentiality changes in microarchitectural (i.e., unspecified in and integrity guarantees to programs running the instruction set architecture) structures or con- inside them. Enclaves are secure even in the pres- tention on microarchitectural CPU resources to ence of a malicious operating system, hypervisor, extract otherwise-unavailable secret information. or firmware. Enclaves are also resilient to physical Processor vendors have invested signific- attacks from outside the CPU package, such as ant effort3 to roll out mitigations for the earliest probes on the memory bus. discovered speculative execution attacks, Melt- At a high level, SGX achieves these strong secu- down2 and Spectre.1 rity guarantees by encrypting the enclave memory Unfortunately these and protecting it with a secure authentication code, measures are inef- Foreshadow allows the making the associated cryptographic keys inaccessi- fective against Fore- attacker code direct ble to software. Finally, SGX provides a remote attes- shadow (also known access to arbitrary tation mechanism. Attestation allows enclaves to as “L1 Terminal physical addresses prove to remote parties that the code and data Fault (L1TF)” in through speculative upon which they operate are unmodified and, impor- Intel’s product liter- wrong-path execution. tantly, the processor upon which they execute is a ature4). Foreshadow genuine (hence, presumed secure) Intel processor. allows the attacker code direct access to arbitrary Notwithstanding its strong security guaran- physical addresses through speculative wrong- tees, SGX does not protect against microarc- path execution. Unlike previously disclosed specu- hitectural side-channel attacks. Since their lative execution attacks, this vulnerability fully sub- introduction over a decade ago, microarchitec- verts the isolation provided by the traditional tural attacks have been used to break numerous virtual memory abstraction, upon which the classic cryptographic implementations, track program security mechanisms of operating systems and vir- behavior, and create covert communication chan- tual machines are built, by allowing attackers to nels. Since SGX’s release, there have been many access data that has no virtual address mapping. works that demonstrated side-channel attacks on The key restriction of Foreshadow/L1TF is that as SGX enclaves (e.g., work presented by Xu et al.5)— far as we know, only physical addresses cached in exploiting vulnerabilities that already exist in the L1 data cache can be exfiltrated. However, as enclaves’ code to leak sensitive data. we show, there are often mechanisms available to Instead, our investigation was motivated by cause the processor to load desired data into the following question: Can an adversary extract cache; in some circumstances, entire address secret data from an enclave’s address space spaces can be exfiltrated. when the code running in that enclave does not itself have any security vulnerabilities? FORESHADOW-SGX Next, given the importance of SGX remote Our international collaboration discovered attestation we asked: What are the implications Foreshadow/L1TF in the context of efforts to inves- of such security breaches on the SGX integrity tigate the security of Intel’s Software Guard guarantees? Can an adversary using a side chan- eXtensions (SGX). SGX is a set of architectural nel erode trust in SGX remote attestation? extensions, which collectively provide strong secu- We answer both questions in the affirmative. rity guarantees to software running in the presence of powerful adversaries. SGX promises secure execution on adversary-controlled machines. OUR CONTRIBUTIONS For example, in the context of cloud computing, Breaking SGX’s Confidentiality SGX guarantees that the processor executes the Foreshadow-SGX exploits the speculative unmodified code provided by the customer and execution features present in all SGX-enabled May/June 2019 67 Top Picks Intel CPUs to read the entire address space of Exploiting SGX’s Privacy Guarantees victim enclaves. Crucially, unlike previous Spec- We note that SGX’s attestation protocol is tre-style speculative execution attacks on SGX, designed with privacy in mind and does not our attack does not require any form of coopera- reveal the identity of the attesting machine to tion or particular flaw in the victim enclave. the remote verifying party. As such, the remote In fact, our attack reads all the secrets of the party has no way of telling which keys were used victim enclave without requiring that enclave to for attestation. Consequently, until revoked by execute any instruction. Intel, even a single leaked attestation key can be used for all malicious simulators, without the remote parties being able to distinguish them Breaking the Integrity of Sealed Data from genuine SGX machines. Thus, the leak of Going beyond the attacks on the SGX confi- even a single key jeopardizes the trustworthi- dentiality properties, we show that Foreshadow ness of the entire SGX ecosystem. also compromises SGX’s long-term storage integ- rity guarantees. Specifically, beyond secure Demonstrating the Brittleness of the SGX computation, SGX also provides private and Ecosystem authenticated long-term storage, which is imple- To the best of our knowledge, our attack is mented via a special sealing application program- the first direct attack on the confidentiality of ming interface (API). This storage mechanism SGX enclaves that makes no assumptions about allows enclaves to encrypt and verify data stored code running in a victim enclave. By leveraging by the (untrusted) operating system. this attack, the adversary may break the integ- As we show, we can use our attack on SGX’s rity of the SGX long-term storage and the trust- confidentiality to extract the sealing key from a worthiness of the remote attestation protocol. victim enclave that uses the SGX sealing mecha- As such, our work highlights the brittleness of 11 nism. After recovering the sealing key, we use the current SGX design because a flaw in confi- it to unseal and read the sealed information, dentiality leads to a cascading set of compro- then modify and reseal it. As SGX provides no mises that undermine the root of trust in the means to detect such a change, the victim con- ecosystem. sequently operates on data corrupted by the attacker. First real demonstration of the L1TF vulnerability Our international collaboration reported Breaking Remote Attestation our proof-of-concept exploit of SGX to Intel. Finally, we turn our attention to SGX’s remote Prompted by our reports, Intel subsequently dis- attestation mechanism, which allows an enclave covered and revealed the underlying L1TF micro- to prove to a remote party that it has been ini- architectural flaw, with consequences much tialized correctly and is executing on a genuine broader than SGX, including subverting memory (presumably secure) Intel processor. protections essential for cloud computing. As we show, we can mount our attacks on enclaves written by Intel and extract their sealing BACKGROUND—SIDE-CHANNEL key. Using the extracted sealing key, we then AND SPECULATIVE EXECUTION unseal the persistent storage of the SGX Quoting ATTACKS Enclave, which contains the machine’s private We briefly explain past side-channel and spe- attestation key. With this key, we can construct culative execution attack mechanisms. malicious SGX simulators that can forge the attes- tation process, masquerading as
Load more

Recommended publications
  • Computer Science 246 Computer Architecture Spring 2010 Harvard University
    Computer Science 246 Computer Architecture Spring 2010 Harvard University Instructor: Prof. David Brooks [email protected] Dynamic Branch Prediction, Speculation, and Multiple Issue Computer Science 246 David Brooks Lecture Outline • Tomasulo’s Algorithm Review (3.1-3.3) • Pointer-Based Renaming (MIPS R10000) • Dynamic Branch Prediction (3.4) • Other Front-end Optimizations (3.5) – Branch Target Buffers/Return Address Stack Computer Science 246 David Brooks Tomasulo Review • Reservation Stations – Distribute RAW hazard detection – Renaming eliminates WAW hazards – Buffering values in Reservation Stations removes WARs – Tag match in CDB requires many associative compares • Common Data Bus – Achilles heal of Tomasulo – Multiple writebacks (multiple CDBs) expensive • Load/Store reordering – Load address compared with store address in store buffer Computer Science 246 David Brooks Tomasulo Organization From Mem FP Op FP Registers Queue Load Buffers Load1 Load2 Load3 Load4 Load5 Store Load6 Buffers Add1 Add2 Mult1 Add3 Mult2 Reservation To Mem Stations FP adders FP multipliers Common Data Bus (CDB) Tomasulo Review 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 LD F0, 0(R1) Iss M1 M2 M3 M4 M5 M6 M7 M8 Wb MUL F4, F0, F2 Iss Iss Iss Iss Iss Iss Iss Iss Iss Ex Ex Ex Ex Wb SD 0(R1), F0 Iss Iss Iss Iss Iss Iss Iss Iss Iss Iss Iss Iss Iss M1 M2 M3 Wb SUBI R1, R1, 8 Iss Ex Wb BNEZ R1, Loop Iss Ex Wb LD F0, 0(R1) Iss Iss Iss Iss M Wb MUL F4, F0, F2 Iss Iss Iss Iss Iss Ex Ex Ex Ex Wb SD 0(R1), F0 Iss Iss Iss Iss Iss Iss Iss Iss Iss M1 M2
    [Show full text]
  • 2020 Sonicwall Cyber Threat Report
    2020 SONICWALL CYBER THREAT REPORT sonicwall.com I @sonicwall TABLE OF CONTENTS 3 A NOTE FROM BILL 4 CYBERCRIMINAL INC. 11 2019 GLOBAL CYBERATTACK TRENDS 12 INSIDE THE SONICWALL CAPTURE LABS THREAT NETWORK 13 KEY FINDINGS FROM 2019 13 SECURITY ADVANCES 14 CRIMINAL ADVANCES 15 FASTER IDENTIFICATION OF ‘NEVER-BEFORE-SEEN’ MALWARE 16 TOP 10 CVES EXPLOITED IN 2019 19 ADVANCEMENTS IN DEEP MEMORY INSPECTION 23 MOMENTUM OF PERIMETER-LESS SECURITY 24 PHISHING DOWN FOR THIRD STRAIGHT YEAR 25 CRYPTOJACKING CRUMBLES 27 RANSOMWARE TARGETS STATE, PROVINCIAL & LOCAL GOVERNMENTS 31 FILELESS MALWARE SPIKES IN Q3 32 ENCRYPTED THREATS GROWING CONSISTENTLY 34 IOT ATTACK VOLUME RISING 35 WEB APP ATTACKS DOUBLE IN 2019 37 PREPARING FOR WHAT’S NEXT 38 ABOUT SONICWALL 2 A NOTE FROM BILL The boundaries of your digital empire are In response, SonicWall and our Capture Labs limitless. What was once a finite and threat research team work tirelessly to arm defendable space is now a boundless organizations, enterprises, governments and territory — a vast, sprawling footprint of businesses with actionable threat devices, apps, appliances, servers, intelligence to stay ahead in the global cyber networks, clouds and users. arms race. For the cybercriminals, it’s more lawless And part of that dedication starts now with than ever. Despite the best intentions of the 2020 SonicWall Cyber Threat Report, government agencies, law enforcement and which provides critical threat intelligence to oversight groups, the current cyber threat help you better understand how landscape is more agile than ever before. cybercriminals think — and be fully prepared for what they’ll do next.
    [Show full text]
  • Internet Security Threat Report Volume 24 | February 2019
    ISTRInternet Security Threat Report Volume 24 | February 2019 THE DOCUMENT IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENT. THE INFORMATION CONTAINED IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE. INFORMATION OBTAINED FROM THIRD PARTY SOURCES IS BELIEVED TO BE RELIABLE, BUT IS IN NO WAY GUARANTEED. SECURITY PRODUCTS, TECHNICAL SERVICES, AND ANY OTHER TECHNICAL DATA REFERENCED IN THIS DOCUMENT (“CONTROLLED ITEMS”) ARE SUBJECT TO U.S. EXPORT CONTROL AND SANCTIONS LAWS, REGULATIONS AND REQUIREMENTS, AND MAY BE SUBJECT TO EXPORT OR IMPORT REGULATIONS IN OTHER COUNTRIES. YOU AGREE TO COMPLY STRICTLY WITH THESE LAWS, REGULATIONS AND REQUIREMENTS, AND ACKNOWLEDGE THAT YOU HAVE THE RESPONSIBILITY TO OBTAIN ANY LICENSES, PERMITS OR OTHER APPROVALS THAT MAY BE REQUIRED IN ORDER FOR YOU TO EXPORT, RE-EXPORT, TRANSFER IN COUNTRY OR IMPORT SUCH CONTROLLED ITEMS. TABLE OF CONTENTS 1 2 3 BIG NUMBERS YEAR-IN-REVIEW FACTS AND FIGURES METHODOLOGY Formjacking Messaging Cryptojacking Malware Ransomware Mobile Living off the land Web attacks and supply chain attacks Targeted attacks Targeted attacks IoT Cloud Underground economy IoT Election interference MALICIOUS
    [Show full text]
  • Systematization of Vulnerability Discovery Knowledge: Review
    Systematization of Vulnerability Discovery Knowledge Review Protocol Nuthan Munaiah and Andrew Meneely Department of Software Engineering Rochester Institute of Technology Rochester, NY 14623 {nm6061,axmvse}@rit.edu February 12, 2019 1 Introduction As more aspects of our daily lives depend on technology, the software that supports this technology must be secure. We, as users, almost subconsciously assume the software we use to always be available to serve our requests while preserving the confidentiality and integrity of our information. Unfortunately, incidents involving catastrophic software vulnerabilities such as Heartbleed (in OpenSSL), Stagefright (in Android), and EternalBlue (in Windows) have made abundantly clear that software, like other engineered creations, is prone to mistakes. Over the years, Software Engineering, as a discipline, has recognized the potential for engineers to make mistakes and has incorporated processes to prevent such mistakes from becoming exploitable vulnerabilities. Developers leverage a plethora of processes, techniques, and tools such as threat modeling, static and dynamic analyses, unit/integration/fuzz/penetration testing, and code reviews to engineer secure software. These practices, while effective at identifying vulnerabilities in software, are limited in their ability to describe the engineering failures that may have led to the introduction of vulnerabilities. Fortunately, as researchers propose empirically-validated metrics to characterize historical vulnerabilities, the factors that may have led to the introduction of vulnerabilities emerge. Developers must be made aware of these factors to help them proactively consider security implications of the code that they contribute. In other words, we want developers to think like an attacker (i.e. inculcate an attacker mindset) to proactively discover vulnerabilities.
    [Show full text]
  • Ghostbuster: Understanding and Overcoming the Pitfalls of Transient Execution Vulnerability Checkers
    GhostBuster: understanding and overcoming the pitfalls of transient execution vulnerability checkers Andrea Mambretti∗y, Pasquale Convertiniy, Alessandro Sorniottiy, Alexandra Sandulescuy, Engin Kirda∗ and Anil Kurmusy ∗Khoury College of Computer Sciences, Northeastern University, Boston, USA Email: fmbr, [email protected] y IBM Research - Zurich, Rueschlikon, Switzerland Email: [email protected], faso, asa, [email protected] Abstract—Transient execution vulnerabilities require system co-located thread, and the threat model requires that the victim administrators to evaluate whether their systems are vulnerable process contains a side channel primitive allowing leakage of and whether available mitigations are enabled. They are aided sensitive data. While some of these attacks are exploitable in in this task by multiple community-developed tools, transient real-world settings, others have not left the realm of theoretical execution vulnerability checkers. Yet, no analysis of these tools vulnerabilities. exists, in particular with respect to their shortcomings and whether they might mislead administrators into a false sense Owing to the high number of transient execution attacks of security. In this paper, we provide the first comprehensive (both practical and theoretical) and the multitude of mitigation analysis of these tools and underpinning methodologies. We mechanisms, the degree to which systems are safe against run the tools on a large set of combinations of Intel/AMD speculative execution attackers is often hard to determine. The architectures and Linux kernel versions and report on their determination is made even more complex by the fact that a efficacy and shortcomings. We also run these tools on 17 of the most prominent cloud providers, report the collected results system might be affected by a certain microarchitectural attack and present the current status on the preparedness of the IT vector, while being safe in practice because the conditions of hosting industry against this class of attacks.
    [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]
  • Public Clouds and Vulnerable Cpus: Are We Secure? FOSDEM 2020
    Public clouds and vulnerable CPUs: are we secure? FOSDEM 2020 Vitaly Kuznetsov <[email protected]> About About myself ● Focusing (mostly) on Linux kernel ● My areas of interest include: ○ Linux as guest on public clouds (AWS, Azure, Aliyun,...) ○ Linux as guest on Hyper-V ○ Hyper-V Enlightenments in KVM ○ Running nested KVM on Hyper-V ○ Running nested Hyper-V on KVM Speculative vulnerabilities Speculative vulnerabilities discovered in the past few years: ● Spectre v1 ○ SWAPGS ● Spectre v2 ● Meltdown (Spectre v3) ● SSB (Spectre v4/NG) ● L1TF (AKA Foreshadow/Spectre v5) ● MDS & TAA Speculative vulnerabilities Speculative Execution Side Channel Methods Intel: “The concept behind speculative execution is that instructions are executed ahead of knowing that they are required. [...] By executing instructions speculatively, performance can be increased by minimizing latency and extracting greater parallelism. …. While speculative operations do not affect the architectural state of the processor, they can affect the microarchitectural state, such as information stored in Translation Lookaside Buffers (TLBs) and caches. ... A side channel method works by gaining information through observing the system, such as by measuring microarchitectural properties about the system. Unlike buffer overflows and other vulnerability classes, side channels do not directly influence the execution of the program, nor do they allow data to be modified or deleted. ” Speculative vulnerabilities and public clouds When running on a public cloud … but my cloud provider
    [Show full text]
  • OS and Compiler Considerations in the Design of the IA-64 Architecture
    OS and Compiler Considerations in the Design of the IA-64 Architecture Rumi Zahir (Intel Corporation) Dale Morris, Jonathan Ross (Hewlett-Packard Company) Drew Hess (Lucasfilm Ltd.) This is an electronic reproduction of “OS and Compiler Considerations in the Design of the IA-64 Architecture” originally published in ASPLOS-IX (the Ninth International Conference on Architectural Support for Programming Languages and Operating Systems) held in Cambridge, MA in November 2000. Copyright © A.C.M. 2000 1-58113-317-0/00/0011...$5.00 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 for profit or commercial advantage and that copies bear this notice and the full cita- tion on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permis- sion and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or [email protected]. ASPLOS 2000 Cambridge, MA Nov. 12-15 , 2000 212 OS and Compiler Considerations in the Design of the IA-64 Architecture Rumi Zahir Jonathan Ross Dale Morris Drew Hess Intel Corporation Hewlett-Packard Company Lucas Digital Ltd. 2200 Mission College Blvd. 19447 Pruneridge Ave. P.O. Box 2459 Santa Clara, CA 95054 Cupertino, CA 95014 San Rafael, CA 94912 [email protected] [email protected] [email protected] [email protected] ABSTRACT system collaborate to deliver higher-performance systems.
    [Show full text]
  • Selective Eager Execution on the Polypath Architecture
    Selective Eager Execution on the PolyPath Architecture Artur Klauser, Abhijit Paithankar, Dirk Grunwald [klauser,pvega,grunwald]@cs.colorado.edu University of Colorado, Department of Computer Science Boulder, CO 80309-0430 Abstract average misprediction latency is the sum of the architected latency (pipeline depth) and a variable latency, which depends on data de- Control-flow misprediction penalties are a major impediment pendencies of the branch instruction. The overall cycles lost due to high performance in wide-issue superscalar processors. In this to branch mispredictions are the product of the total number of paper we present Selective Eager Execution (SEE), an execution mispredictions incurred during program execution and the average model to overcome mis-speculation penalties by executing both misprediction latency. Thus, reduction of either component helps paths after diffident branches. We present the micro-architecture decrease performance loss due to control mis-speculation. of the PolyPath processor, which is an extension of an aggressive In this paper we propose Selective Eager Execution (SEE) and superscalar, out-of-order architecture. The PolyPath architecture the PolyPath architecture model, which help to overcome branch uses a novel instruction tagging and register renaming mechanism misprediction latency. SEE recognizes the fact that some branches to execute instructions from multiple paths simultaneously in the are predicted more accurately than others, where it draws from re- same processor pipeline, while retaining maximum resource avail- search in branch confidence estimation [4, 6]. SEE behaves like ability for single-path code sequences. a normal monopath speculative execution architecture for highly Results of our execution-driven, pipeline-level simulations predictable branches; it predicts the most likely successor path of a show that SEE can improve performance by as much as 36% for branch, and evaluates instructions only along this path.
    [Show full text]
  • Viewed Through the Prism of Clausewitzian Strategy
    CYBERWAR – VIEWED THROUGH THE PRISM OF CLAUSEWITZIAN STRATEGY Commodore Vishwanathan K Ganapathi, VSM Introduction In a globalised world where speed and reliability of information exchange is thesine qua non of technological advancement, the importance of cyberspace to a country is immeasurable. Knowledge and awareness, which derive from the degree to which cyberspace can be exploited for rapidly storing, manipulating and disseminating data, have become important measures of a nation’s power.1 As a consequence, the destruction or disruption of any of the constituent elements of cyberspace from a cyber attack would not just blunt a country’s ability to gain strategic advantage from its technological superiority but would gravely threaten its security as well. Depending on their intensity and complexity, cyber attacks can inflict a wide spectrum of damage ranging from less dangerous depredations like the theft of personal information and digital heists to highly destructive actions like the disruption of critical infrastructure- ‘the facilities, systems, sites and networks necessary for the delivery of essential services and functions’2 - industrial sabotage, subversion, data destruction or theft of sensitive information. It is the latter category, most often believed to be orchestrated for political reasons by a potential adversary, which has transformed cyber attacks from being perceived as a trivial problem befitting address by an IT professional to one that merits the focus of policy planners and strategists alike.3 The concerns of governments about the gravity of the threat from cyber attacks stem from the certitude that easily accessible destructive technologies are being exploited by state and non-state actors alike to launch attacks even against powerful adversaries several thousand miles away.
    [Show full text]
  • Igpu: Exception Support and Speculative Execution on Gpus
    Appears in the 39th International Symposium on Computer Architecture, 2012 iGPU: Exception Support and Speculative Execution on GPUs Jaikrishnan Menon, Marc de Kruijf, Karthikeyan Sankaralingam Department of Computer Sciences University of Wisconsin-Madison {menon, dekruijf, karu}@cs.wisc.edu Abstract the evolution of traditional CPUs to illuminate why this pro- gression appears natural and imminent. Since the introduction of fully programmable vertex Just as CPU programmers were forced to explicitly man- shader hardware, GPU computing has made tremendous age CPU memories in the days before virtual memory, for advances. Exception support and speculative execution are almost a decade, GPU programmers directly and explicitly the next steps to expand the scope and improve the usabil- managed the GPU memory hierarchy. The recent release ity of GPUs. However, traditional mechanisms to support of NVIDIA’s Fermi architecture and AMD’s Fusion archi- exceptions and speculative execution are highly intrusive to tecture, however, has brought GPUs to an inflection point: GPU hardware design. This paper builds on two related in- both architectures implement a unified address space that sights to provide a unified lightweight mechanism for sup- eliminates the need for explicit memory movement to and porting exceptions and speculation on GPUs. from GPU memory structures. Yet, without demand pag- First, we observe that GPU programs can be broken into ing, something taken for granted in the CPU space, pro- code regions that contain little or no live register state at grammers must still explicitly reason about available mem- their entry point. We then also recognize that it is simple to ory. The drawbacks of exposing physical memory size to generate these regions in such a way that they are idempo- programmers are well known.
    [Show full text]
  • A Survey of Published Attacks on Intel
    1 A Survey of Published Attacks on Intel SGX Alexander Nilsson∗y, Pegah Nikbakht Bideh∗, Joakim Brorsson∗zx falexander.nilsson,pegah.nikbakht_bideh,[email protected] ∗Lund University, Department of Electrical and Information Technology, Sweden yAdvenica AB, Sweden zCombitech AB, Sweden xHyker Security AB, Sweden Abstract—Intel Software Guard Extensions (SGX) provides a Unfortunately, a relatively large number of flaws and attacks trusted execution environment (TEE) to run code and operate against SGX have been published by researchers over the last sensitive data. SGX provides runtime hardware protection where few years. both code and data are protected even if other code components are malicious. However, recently many attacks targeting SGX have been identified and introduced that can thwart the hardware A. Contribution defence provided by SGX. In this paper we present a survey of all attacks specifically targeting Intel SGX that are known In this paper, we present the first comprehensive review to the authors, to date. We categorized the attacks based on that includes all known attacks specific to SGX, including their implementation details into 7 different categories. We also controlled channel attacks, cache-attacks, speculative execu- look into the available defence mechanisms against identified tion attacks, branch prediction attacks, rogue data cache loads, attacks and categorize the available types of mitigations for each presented attack. microarchitectural data sampling and software-based fault in- jection attacks. For most of the presented attacks, there are countermeasures and mitigations that have been deployed as microcode patches by Intel or that can be employed by the I. INTRODUCTION application developer herself to make the attack more difficult (or impossible) to exploit.
    [Show full text]