PaperlayerView exact revision on arXiv

Source-linked AI summary

MI6: Secure Enclaves in a Speculative Out-of-Order Processor

Thomas Bourgeat, Ilia Lebedev, Andrew Wright, Sizhuo Zhang, Arvind, Srinivas Devadas

arXiv:1812.09822v5cs.CRcs.OS

TL;DR

MI6 addresses the failure of conventional process isolation against microarchitectural side channels and speculative execution attacks. It implements secure enclaves on a speculative out-of-order processor using memory-hierarchy isolation, a purge instruction, and protected monitor execution, with reasonable overhead but important threat-model and expressivity boundaries.

  • Problem

    Microarchitectural side channels and control-flow speculation attacks let untrusted software infer secrets through shared processor state, undermining conventional process isolation.

  • Method

    MI6 combines physical resource isolation, a purge instruction, and security-monitor protections to support enclaves on a speculative out-of-order processor.

  • Results

    MI6 supports secure enclaves with reasonable overhead in an aggressive speculative out-of-order processor prototype.

  • Takeaways & Limitations

    Enclaves can restore strong isolation in modern speculative processors, while further work is needed to reduce overhead and support more expressive software.

  • Takeaways & Limitations

    MI6 excludes physical attacks, denial of service, hardware bugs, shared performance-counter attacks, and public-API leaks; variable-latency DRAM timing independence remains future work.

Abstract

from arXiv · show

Recent attacks have broken process isolation by exploiting microarchitectural side channels that allow indirect access to shared microarchitectural state. Enclaves strengthen the process abstraction to restore isolation guarantees. We propose MI6, an aggressive, speculative out-of-order processor capable of providing secure enclaves under a threat model that includes an untrusted OS and an attacker capable of mounting any software attack currently considered practical, including control flow speculation attacks. MI6 is inspired by Sanctum [16] and extends its isolation guarantee to more realistic memory hierarchies. It also introduces a purge instruction, which is used only when a secure process is scheduled, and implements it for a complex processor microarchitecture. We model the performance impact of enclaves in MI6 through FPGA emulation on AWS F1 FPGAs by running SPEC CINT2006 benchmarks on top of an untrusted Linux OS. Security comes at the cost of approximately 16.4% average slowdown for protected programs.

1. INTRODUCTION

MI6 strengthens the process abstraction with enclaves that isolate secure tasks from untrusted software and shared microarchitectural state, including under speculative execution attacks. The paper develops and evaluates this design on an aggressive speculative out-of-order processor.

  • Motivation: Microarchitectural side channels and control-flow speculation attacks undermine conventional process isolation by exposing shared state to untrusted software.The threat model includes a privileged software adversary and attacks mounted through shared hardware resources rather than the enclave’s public API.
  • Enclave abstraction: Enclaves provide secure processes with stronger isolation guarantees while coexisting with ordinary processes under an untrusted operating system.A trusted security monitor mediates enclave transitions and verifies resource allocation even if the OS is compromised.
  • Security goal: Strong isolation requires separation across shared cache and other microarchitectural resources, not merely unique enclave memory addresses.The stated property requires co-located attacks to be no more effective than attacks from another machine communicating only through the victim’s public API.
  • Evaluation: The evaluation models enclave overhead on AWS F1 FPGA emulation while running benchmarks on an untrusted Linux OS.The supplied introduction identifies the platform and operating-system setting but does not state the headline slowdown here.
  • Contributions: MI6 combines broader memory-hierarchy isolation, a purge instruction for speculative processor state, and security-monitor changes for speculative execution.These contributions target subtle queue and arbitration channels, decouple purge complexity from the out-of-order core, and protect the monitor itself.

2. ENCLAVES AND ISOLATED EXECUTION

MI6 defines enclaves as isolated software environments whose memory, execution, and shared-resource behavior remain protected from other software. A trusted security monitor composes hardware isolation primitives into this abstraction against a powerful software adversary.

  • Enclave abstraction: Enclaves execute entirely in disjoint isolated memory and expose controlled entry points rather than transparently using untrusted system services.System services must be proxied through untrusted software, so enclave software trades expressivity for security.
  • Isolation approach: MI6 implements flushing, constrained instruction fetch, and low-level resource partitioning to establish non-interference between protection domains.A trusted security monitor composes these mechanisms and manages transitions between domain configurations.
  • Trusted base: The trusted computing base includes the processor, DRAM, and security-monitor binary, while the monitor runs in machine mode above the untrusted OS.MI6 isolates enclave software from other software on the same speculative out-of-order processor.
  • Threat model: The adversary may compromise the OS and hypervisor, launch malicious enclaves, and fully understand the platform and loaded software.The threat model focuses on software attacks that interact with enclaves through shared hardware resources outside their public APIs.
  • Threat-model boundaries: MI6 excludes physical-access attacks, denial of service, hardware bugs, shared performance-counter attacks, and leaks already exposed through a victim’s public API.Memory protection can be augmented with encryption and integrity verification or ORAM, but those mechanisms are outside the described isolation design.

3. RELATED WORK

Prior defenses address cache and microarchitectural side channels through partitioning, randomization, or specialized enclave architectures. MI6 builds on Sanctum while extending protection to speculative execution and more realistic shared memory hierarchies.

  • Cache side channels: Cache timing channels can be mounted by unprivileged software and target shared LLC state, coherence, replacement metadata, and directory behavior.Examples include flush+reload, prime+probe, evict+reload, and attacks observing coherence or replacement metadata.
  • Partitioning: Set partitioning blocks cache occupancy sharing without new hardware when page-granular groups of cache sets are allocated to protection domains.Sanctum and MI6 use page coloring to achieve this form of cache-set isolation.
  • Related defenses: CAT allocates LLC ways but can still leak through shared replacement metadata, while DAWG adds protection-domain structure to set-associative resources.These approaches differ from MI6’s broader isolation of shared microarchitectural resources.
  • MI6 design choice: MI6 does not use adaptive cache-area techniques because its enclave cache allocation is not allowed to adapt, preventing use of several randomized or replacement-policy defenses.The limitation applies to techniques such as RPcache, CEASER, SHARP, and RIC.
  • Prior secure processors: Earlier secure processors and SGX did not fully address side-channel threats, with SGX lacking protection against cache timing and control-flow speculation attacks.InvisiSpec hides speculation in the data-cache hierarchy but does not cover other shared microarchitectural state and incurs significant performance cost.
  • Positioning: MI6 extends Sanctum’s enclave isolation to cache, cache-directory, and DRAM-controller bandwidth channels in a more realistic processor hierarchy.Sanctum targets a simpler in-order processor, whereas MI6 addresses a broader attack class in a modern-style hierarchy.

4. BASELINE OOO PROCESSOR

MI6 is built on RiscyOO, an open-source speculative out-of-order RISC-V processor with modern cache, TLB, and speculation features. Supporting enclaves requires memory isolation, comprehensive purging, and a guard on security-monitor speculation.

  • RiscyOO baseline: RiscyOO provides register renaming, branch prediction, non-blocking caches and TLBs, superscalar execution, and speculative loads despite unresolved older branches or addresses.Its coherent shared L2 acts as the LLC and exposes cache-timing and Spectre vulnerabilities in the baseline.
  • Platform: RiscyOO is substantially more complex than Sanctum’s processor and has been prototyped on AWS F1 FPGAs running Linux and SPEC CINT2006.The FPGA implementation completes ref-input benchmarks in slightly more than a day.
  • Required modifications: Supporting enclaves requires physical-address protection throughout the memory hierarchy, a purge operation for separately allocated resources, and a speculation guard for the security monitor.The monitor must avoid speculative loads to arbitrary physical addresses and speculative instruction fetches outside its own binary.
  • Hardware changes: MI6 summarizes its hardware changes as microarchitectural flushing, page-walk checks, machine-mode speculation controls, LLC set and MSHR partitioning, and additional LLC side-channel defenses.These changes are distributed across the processor pipeline, address translation, cache hierarchy, and machine-mode execution.

5. STEADY STATE ISOLATION

MI6 defines isolation beyond ISA-level architectural independence by accounting for timing effects from shared microarchitectural resources. Its guarantees distinguish minor within-cycle contention from major multi-cycle interference and include speculative physical accesses.

  • MI6 treats programs as architecturally independent when one program’s output does not depend on another, excluding timing side channels.
  • The timing model assumes programs can measure the precise timing of microarchitectural events, including instruction fetch, issue, execution, and commit.
  • Weak timing independence permits only minor timing leakage, while strong timing independence excludes both minor and major timing leaks.Major leaks arise from waiting multiple cycles for another core; minor leaks arise from same-cycle resource arbitration.
  • A program’s accessed physical addresses include instruction fetches, loads, stores, page-table walks, and speculative accesses.
  • The model assumes all memory is normal memory rather than memory-mapped I/O because devices and drivers are untrusted.

5.1 Establishing Architectural Isolation

Disjoint physical address spaces provide architectural isolation because, without timing observations, one program’s execution cannot affect the other.

  • Disjoint address spaces imply architectural isolation when programs cannot use microarchitectural timing to observe one another.

5.2 Establishing Weak Timing Independence

Weak timing independence requires statically partitioning shared memory-system resources so one program cannot dynamically alter another’s service timing. MI6 applies this principle to caches, MSHRs, DRAM request capacity, and controller scheduling.

  • Dynamic sharing of cache-set entries lets one program evict another’s data, so MI6 statically partitions cache sets by protection domain.MI6 maps pairs of DRAM regions to disjoint LLC cache sets by incorporating the DRAM-region ID into the LLC index.
  • A program filling the LLC’s MSHRs can stall another program’s cache miss, creating a major timing leak; MI6 assigns equal MSHR partitions to processor cores.
  • MI6 limits total cache MSHRs to dmax/2, or approximately dmax/(2N) per core, to prevent DRAM-controller backpressure from delaying requests.Each MSHR can issue up to one write-back request and one read request during its lifetime.
  • A reordering DRAM controller can batch one program’s same-bank requests and change another program’s latency, breaking weak timing independence.
  • The evaluated RiscyOO model uses constant-latency DRAM; variable-latency controllers must instead enforce timing independence across protection domains.The paper leaves exploration of such variable-latency controllers to future work.

5.3 Address Validation for Protection Domains

MI6 separates enclaves from untrusted software through distinct address spaces, per-enclave page tables, routed page faults, and hardware validation of all physical accesses. This validation covers speculative accesses and page-table walks needed for cache-set partitioning.

  • Unlike Sanctum, MI6 gives enclaves separate virtual address spaces, routes page faults to enclaves, and uses per-enclave page tables.These mechanisms block page-fault and page-access side channels involving the untrusted OS.
  • Ensuring cache-set restrictions is difficult because speculative accesses and page-table walks may reach addresses outside explicitly programmed loads and stores.
  • MI6 uses per-core DRAM-region permission bitvectors to suppress speculative or nonspeculative physical accesses outside a program’s allocated regions.
  • MI6 caches DRAM-region permissions in the TLB because aligned regions ensure each 4 KB page belongs to one region.A translation remains legal until the DRAM-region allocation changes.

5.4 Achieving Strong Timing Independence

MI6 strengthens the LLC to eliminate timing dependencies across protection domains, addressing both shared-resource contention and the remaining minor leakages in RiscyOO’s cache pipeline.

  • 5.4.3 LLC with Strong Timing Independence: MI6 achieves strong timing independence by preventing the LLC’s contended resources from creating timing leakage across protection domains.The design addresses the minor leakages that remain after partitioning LLC storage elements.
  • 5.4.3 LLC with Strong Timing Independence: Per-core message merging followed by round-robin arbitration isolates cross-core contention before requests enter the cache-access pipeline.Messages from the same core are merged first, while different cores are arbitrated separately.
  • 5.4.3 LLC with Strong Timing Independence: Splitting the shared UQ into per-core FIFOs confines head-of-line blocking to responses within one core and protection domain.A downgrade request can contend only with responses associated with the same core when the relevant addresses share a cache set.
  • 5.4.4 Qualitative Analysis of Performance Impact: The UQ split and duplicated Downgrade-L1 logic each have zero performance overhead, while retry latency adds only a few negligible cycles for DRAM requests.The Downgrade-L1 logic would otherwise incur latency proportional to the number of cores under round-robin operation.
  • 5.4.4 Qualitative Analysis of Performance Impact: The main performance cost is round-robin arbitration, which gives each of N cores 1/N of SRAM bandwidth and adds roughly N/2 cycles of average pipeline-entry latency.The impact is most concerning for bursty traffic and grows with the number of cores.

6. ISOLATION ACROSS PROTECTION DOMAIN TRANSITIONS

MI6 isolates protection domains across scheduling transitions by purging processor state and restricting privileged monitor execution, while preserving steady-state isolation through dedicated resources and address ranges.

  • 6.1 purge instruction: The purge must cover in-flight core state, including register-renaming structures, reorder buffers, issue queues, speculation tracking, load-store state, and FIFOs.RiscyOO already flushes these states on privilege changes, but equivalent empty states must remain indistinguishable to software.
  • 6.1 purge instruction: Branch predictors require a well-defined public state because their statefulness can support speculative-execution attacks and cross-context leakage.The processor may save and restore predictor state to reduce cold-prediction overhead after context switches.
  • 6.2 Security Monitor Functionality: MI6 restricts arbitrary memory sharing and mediates communication between protection domains through the security monitor.These restrictions defend against timing attacks on shared memory, including attacks involving speculative execution.
  • 6. ISOLATION ACROSS PROTECTION DOMAIN TRANSITIONS: Steady-state isolation combines a uniquely allocated core and address range with page coloring, MSHR partitioning, and memory-request timing isolation.The enclave remains responsible for safeguarding the timing of its public operations.
  • 6. ISOLATION ACROSS PROTECTION DOMAIN TRANSITIONS: MI6 isolates an enclave during scheduling, de-scheduling, creation, and destruction by sanitizing architectural and microarchitectural state at each transition.The security monitor uses purge to flush processor state and software routines to restore architectural state before handing control to the next software context.
  • 6.3 Strong Isolation Argument: Because the security monitor can access arbitrary physical memory, MI6 disables speculation in machine mode to prevent speculative isolation bypasses.The monitor occupies the highest-privilege domain and is treated differently from enclaves and untrusted software.

7. PERFORMANCE EVALUATION

MI6’s performance evaluation isolates the costs of flushing, cache partitioning, MSHR changes, arbitration, and enclave execution using RiscyOO variants and FPGA emulation. Across SPEC CINT2006 benchmarks, protected enclave execution incurs a 16.4% average overhead, while flushing alone averages 5.4%.

  • 7. PERFORMANCE EVALUATION: MI6 evaluates security-related costs with RiscyOO variants including BASE, FLUSH, PART, and additional models for LLC-MSHR partitioning and arbitration.The ideal multiprocessor LLC experiment was approximated with a single core because the FPGA lacked sufficient logic gates and SRAMs.
  • 7.1 Flushing Per-Core Microarchitectural State: 5.4% is the average overhead from flushing per-core microarchitectural state, with a maximum of 10.9% for astar.The overhead includes flush stalls, cold-start cache and TLB misses, and additional branch mispredictions.
  • 7.1 Flushing Per-Core Microarchitectural State: 0.4% of execution time is the average stall cost for flushing microarchitectural states, although xalancbmk reaches 3.2%.The longer xalancbmk stall results from its large number of system calls, which trigger exceptions.
  • 7.1 Flushing Per-Core Microarchitectural State: Branch mispredictions rise from 18.3 to 24.3 per thousand instructions after flushing, explaining the overall 5.4% flushing overhead.For astar, mispredictions increase from 30.1 to 46.2, accompanying its 10.9% maximum overhead.
  • 7.2 Set-Partitioning the LLC: 7.4% is the average overhead from LLC set-partitioning, with a maximum of 21.6% for gcc compared with BASE.Using higher address bits in the LLC index increases average LLC misses from 17.4 to 19.6 per thousand instructions.
  • 7.6 Overall Performance Overheads of MI6: 16.4% is the average execution-time overhead for MI6 enclave programs, reaching 34.8% for gcc compared with BASE.The F+P+M+A configuration combines FLUSH, PART, MISS, and ARB; turning off speculation is omitted from this estimate.

8. CONCLUSION

MI6 supports enclaves on an aggressive speculative out-of-order processor, restoring isolation guarantees under a specified threat model with reasonable overhead.

  • MI6 supports enclaves on an aggressive speculative out-of-order processor while restoring isolation guarantees under a specified threat model.
Loading 1812.09822v5…