ACM SIGArch: Speculating about speculation: on the (lack of) security guarantees of Spectre-V1 mitigations

Spectre and Meltdown opened the Pandora box of a new class of speculative execution attacks that defeat standard memory protection mechanisms. These attacks are not theoretical, they pose a real and immediate security threat, and have been reportedly exploited by cybercriminals.[…]

Speculating about speculation: on the (lack of) security guarantees of Spectre-V1 mitigations

 

Intel MPX Explained

https://twitter.com/kayseesee/status/832664911578664960

 

Intel MPX Explained: An Empirical Study of Intel MPX and Software-based Bounds Checking Approaches

Oleksii Oleksenko, Dmitrii Kuvaiskii, Pramod Bhatotia, Pascal Felber, Christof Fetzer

(Submitted on 2 Feb 2017)

    Memory-safety violations are a prevalent cause of both reliability and security vulnerabilities in systems software written in unsafe languages like C/C++. Unfortunately, all the existing software-based solutions to this problem exhibit high performance overheads preventing them from wide adoption in production runs. To address this issue, Intel recently released a new ISA extension – Memory Protection Extensions (Intel MPX), a hardware-assisted full-stack solution to protect against memory safety violations. In this work, we perform an exhaustive study of the Intel MPX architecture to understand its advantages and caveats. We base our study along three dimensions: (a) performance overheads, (b) security guarantees, and (c) usability issues. To put our results in perspective, we compare Intel MPX with three prominent software-based approaches: (1) trip-wire – AddressSanitizer, (2) object-based – SAFECode, and (3) pointer-based – SoftBound. Our main conclusion is that Intel MPX is a promising technique that is not yet practical for widespread adoption. Intel MPX’s performance overheads are still high (roughly 50% on average), and the supporting infrastructure has bugs which may cause compilation or runtime errors. Moreover, we showcase the design limitations of Intel MPX: it cannot detect temporal errors, may have false positives and false negatives in multithreaded code, and its restrictions on memory layout require substantial code changes for some programs.

https://arxiv.org/abs/1702.00719

See also:

https://intel-mpx.github.io/
https://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions

more on SCONE

Re: SCONE, mentioned here: https://firmwaresecurity.com/2017/01/07/secure-linux-containers-with-intel-sgx/

 

SCONE: Secure Linux Containers with Intel SGX
Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran, Dan O’Keeffe, Mark L Stillwell, David Goltzsche, Dave Eyers, Rüdiger Kapitza, Peter Pietzuch, Christof Fetzer

In multi-tenant environments, Linux containers managed by Docker or Kubernetes have a lower resource footprint, faster startup times, and higher I/O performance compared to virtual machines (VMs) on hypervisors. Yet their weaker isolation guarantees, enforced through software kernel mechanisms, make it easier for attackers to compromise the confidentiality and integrity of application data within containers. We describe SCONE, a secure container mechanism for Docker that uses the SGX trusted execution support of Intel CPUs to protect container processes from outside attacks. The design of SCONE leads to (i) a small trusted computing base (TCB) and (ii) a low performance overhead: SCONE offers a secure C standard library interface that transparently encrypts/decrypts I/O data; to reduce the performance impact of thread synchronization and system calls within SGX enclaves, SCONE supports user-level threading and asynchronous system calls. Our evaluation shows that it protects unmodified applications with SGX, achieving 0.6✓–1.2✓ of native throughput.[…]

https://www.usenix.org/conference/osdi16/technical-sessions/presentation/arnautov

Click to access osdi16-arnautov.pdf

Click to access osdi16_slides_knauth.pdf