Fig 1 - uploaded by Giorgi Maisuradze
Content may be subject to copyright.
![CPU Core Pipeline Functionality of the Haswell Microarchitecture [18].](profile/Giorgi-Maisuradze-2/publication/322498455/figure/fig1/AS:946889331597316@1602767417865/CPU-Core-Pipeline-Functionality-of-the-Haswell-Microarchitecture-18.png)
CPU Core Pipeline Functionality of the Haswell Microarchitecture [18].
Source publication
Whenever modern CPUs encounter a conditional branch for which the condition cannot be evaluated yet, they predict the likely branch target and speculatively execute code. Such pipelining is key to optimizing runtime performance and is incorporated in CPUs for more than 15 years. In this paper, to the best of our knowledge, we are the first to study...
Context in source publication
Similar publications
Modern convolutional neural networks (CNNs) are often trained on pre-set data sets with a fixed size. As for the large-scale applications of satellite images, for example, global or regional mappings, these images are collected incrementally by multiple stages in general. In other words, the sizes of training datasets might be increased for the tas...
Template-based program repair research is in need for a common ground to express fix patterns in a standard and reusable manner. We propose to build on the concept of generic patch (also known as semantic patch), which is widely used in the Linux community to automate code evolution. We advocate that generic patches could provide at the same time a...
Citations
... However, only a small number of loads/stores will be speculatively queued [40]. As long as we limit the distance between successive accesses (we limit it to 64kB), and ensure that base pointers are always valid (masking them where needed), we can make such optimizations speculation-aware. ...
Information leakage vulnerabilities (or simply info leaks) such as out-of-bounds/uninitialized reads in the architectural or speculative domain pose a significant security threat, allowing attackers to leak sensitive data such as crypto keys. At the same time, such vulnerabilities are hard to efficiently mitigate, as every (even speculative) memory load operation needs to be potentially instrumented against unauthorized reads. Existing confidentiality-preserving solutions based on data isolation label memory objects with different (e.g., sensitive vs. nonsensitive) colors, color load operations accordingly using static points-to analysis, and instrument them to enforce color-matching invariants at run time. Unfortunately, the reliance on conservative points-to analysis introduces overapproximations that are detrimental to security (or further degrade performance). In this paper, we propose Type-based Data Isolation (TDI), a new practical design point in the data isolation space to mitigate info leaks. TDI isolates memory objects of different colors in separate memory arenas and uses efficient compiler instrumentation to constrain loads to the arena of the intended color by construction. TDI's arena-based design moves the instru-mentation from loads to pointer arithmetic operations, enabling new aggressive speculation-aware performance optimizations and eliminating the need for points-to analysis. Moreover, TDI's color management is flexible. TDI can support a few-color scheme with sensitive data annotations similar to prior work (e.g., 2 colors) or a many-color scheme based on basic type analysis (i.e., one color per object type). The latter approach provides fine-grained data isolation, eliminates the need for annotations, and enforces strong color-matching invariants equivalent to ideal (context-sensitive) type-based points-to analysis. Our results show that TDI can efficiently support such strong security invariants, at average performance overheads of <10% on SPEC CPU2006 and nginx.
... Rowhammer; (a) sigle-sided, (b) double-sided So far, various forms of Spectre attack have been published[56][57][58]. ...
... To achieve this goal, systems optimize the execution of "common execution paths" and widely use different speculative micro-architectural mechanisms such as prefetching, outof-order execution, value prediction, and more. These mechanisms have been shown [53][54][55] to leak information side-channels leading to successful attacks. However, since these mechanisms are essential to cope with the growing demand for computing power, most SoC providers prefer to compromise security over giving up power or performance. ...
A rising tide of exploits, in the recent years, following a steady discovery of the many vulnerabilities pervasive in modern computing systems has led to a growing number of studies in designing systems-on-chip (SoCs) with security as a first-class consideration. Following the momentum behind RISC-V-based systems in the public domain, much of this effort targets RISC-V-based SoCs; most ideas, however, are independent of this choice. In this manuscript, we present a consolidation of our early efforts along these lines in designing a secure SoC around RISC-V, named ITUS. In particular, we discuss a set of primitive building blocks of a secure SoC and present some of the implemented security subsystems using these building blocks—such as secure boot, memory protection, PUF-based key management, a countermeasure methodology for RISC-V micro-architectural side-channel leakage, and an integration of the open keystone-enclaves for TEE. The current ITUS SoC prototype, integrating the discussed security subsystems, was built on top of the lowRISC project; however, these are portable to any other SoC code base. The SoC prototype has been evaluated on an FPGA.
... Long dependence chain. Constructing a long data dependence chain for computing source operands can also be used to provide a longer timing window for stable speculative executions [22]. ...
Speculative execution side-channel vulnerabilities such as Spectre reveal that conventional architecture designs lack security consideration. This paper proposes a software transparent defense mechanism, named as Conditional Speculation, against Spectre vulnerabilities found on traditional out-of-order microprocessors. It introduces the concept of security dependence to mark speculative memory instructions which could leak information with potential security risk. More specifically, security-dependent instructions are detected and marked with suspect speculation flags in the Issue Queue. All the instructions can be speculatively issued for execution in accordance with the classic out-of-order pipeline. For those instructions with suspect speculation flags, they are considered as safe instructions if their speculative execution will not refill new cache lines. Otherwise, they are considered as unsafe instructions and thus not allowed to execute speculatively. To reduce the performance impact from not executing unsafe instructions speculatively, we investigate two filtering mechanisms, Cache-hit based Hazard Filter and Trusted Page Buffer based Hazard Filter to filter out false security hazards. As for true security hazards, we fetch them from lower level caches or memory to a speculative buffer temporarily, and refill them after confirming that they are in correct execution path. The experimental results show that the hardware and performance overhead is minimal.
... For a program instruction to be processed in the processor it might takes several clock cycles before the outcome is known, rather than wasting the cycle by putting it them in idle, the processor speculatively execute the program to product possible outcomes [4]. For any variation, the processor may start to learn the function that frequently used or accessed by the program and the program will speculatively execute the function during the idle time even without the acknowledgement of the user [1,4,5]. ...
... For a program instruction to be processed in the processor it might takes several clock cycles before the outcome is known, rather than wasting the cycle by putting it them in idle, the processor speculatively execute the program to product possible outcomes [4]. For any variation, the processor may start to learn the function that frequently used or accessed by the program and the program will speculatively execute the function during the idle time even without the acknowledgement of the user [1,4,5]. ...
Speculative execution (Spectre) and Meltdown is a chip attempting to predict the future in order to improve the system performance which involves multiple logical branches, it will start working out the math for all those branches before the program even has to decide between them. Normally, it works together with caching which is to speed up the memory access by filled with the data that will need some and often the output of the speculative execution is stored here. The speculative execution and caching in the operating system improve the overall system and operating system performance through the prediction of data or resources to be used and cache memory is for quick access of data or resources. The problem arises where this function could allow potential attackers to get access to data they should not have access by exploiting the Spectre attacks and Meltdown. Spectre attacks and meltdown open up the possibilities for dangerous attacks which involved the breach of security and confidentiality of the user. Various techniques and patches have been introduced to mitigating the Spectre attack and meltdown. In this paper, we present the view various variants of attack from the speculative execution with its mitigation techniques.
... Side-Channels. To date, numerous attacks (e.g., [29,30,33,35,50]) have been proposed for leaking information across security domains by leveraging architectural or micro-architectural artifacts. ...
The success of cloud computing has shown that the cost and convenience benefits of outsourcing infrastructure, platform, and software resources outweigh concerns about confidentiality. Still, many businesses and individuals resist moving private data to cloud providers due to intellectual property and privacy reasons. A recent wave of hardware virtualization technologies aims to alleviate these concerns by offering encrypted virtualization features that support data confidentiality of guest virtual machines (e.g., by transparently encrypting memory) even when running on top untrusted hypervisors. We introduce two new attacks that can breach the confidentiality of protected enclaves. First, we show how a cloud adversary can judiciously inspect the general purpose registers to unmask the computation that passes through them. Specifically, we demonstrate a set of attacks that can precisely infer the executed instructions and eventually capture sensitive data given only indirect access to the CPU state as observed via the general purpose registers. Second, we show that even under a more restrictive environment - where access to the general purpose registers is no longer available - we can apply a different inference attack to recover the structure of an unknown, running, application as a stepping stone towards application fingerprinting. We demonstrate the practicality of these inference attacks by showing how an adversary can identify different applications and even distinguish between versions of the same application and the compiler used, recover data transferred over TLS connections within the encrypted guest, retrieve the contents of sensitive data as it is being read from disk by the guest, and inject arbitrary data within the guest. Taken as a whole, these attacks serve as a cautionary tale of what can go wrong when the state of registers (e.g., in AMD's SEV) and application performance data (e.g. in AMD's SEV-ES) are left unprotected. The latter is the first known attack that was designed to specifically target SEV-ES.
... For a program's instruction to be processed in the processor it might take several clock cycles before the outcome is known, rather of wasting the cycle by putting it them in idle, the processor speculatively executes the program to produce possible outcomes [4]. For any variation, the processor may start to learn the function that frequently used for accessed by the program and the program will speculatively execute the function during the idle time even without the acknowledgment of the user [1,4,7]. In computer security area, speculative execution and caching is part of the protected memory. ...
... Long dependence chain. Constructing a long data dependence chain for computing source operands can also be used to provide longer timing window for stable speculative executions [16]. ...
... This side-effect can leak information about the speculatively accessed data and thus violate confidentiality. The family of SPECTRE attacks [1], [2], [3], [4], [5], [6] demonstrates that the vulnerability affects all modern general-purpose CPUs and poses a serious threat against platforms with multiple tenants. ...
... Figure 9 depicts the results of applying SPECTECTOR to the 210 examples. We highlight the following findings: 4 Insertion of fences is supported by CLANG with the flag -x86-speculative-load-hardening-lfence, by ICC with -mconditional-branch=all-fix, and by VISUAL C++ with /Qspectre 5 Speculative load hardening is supported by CLANG with the flag -x86-speculative-load-hardening. 6 The resulting assembly files are available at https:// spectector.github.io. ...
... These attacks exploit the effects of speculatively executed instructions to leak information. After SPECTRE [2], [4], [6], a number of speculative execution attacks have been discovered that differ in the exploited speculation sources [1], [5], [18], the covert channels [26], [3], [27] used, or the target platforms [28]. We refer the reader to [29] for a survey of speculative execution attacks and their countermeasures. ...
Since the advent of SPECTRE, a number of countermeasures have been proposed and deployed. Rigorously reasoning about their effectiveness, however, requires a well-defined notion of security against speculative execution attacks, which has been missing until now. We present a novel, principled approach for reasoning about software defenses against SPECTRE-style attacks. Our approach builds on speculative non-interference, the first semantic notion of security against speculative execution attacks. We develop SPECTECTOR, an algorithm based on symbolic execution for automatically proving speculative non-interference, or detecting violations. We implement SPECTECTOR in a tool, and we use it to detect subtle leaks -- and optimizations opportunities -- in the way major compilers place SPECTRE countermeasures.
