PaperlayerView exact revision on arXiv

Source-linked AI summary

Inferring Fine-grained Control Flow Inside SGX Enclaves with Branch Shadowing

Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, Hyesoon Kim, Marcus Peinado

arXiv:1611.06952v3cs.CR

TL;DR

The paper addresses whether branch-prediction side channels can expose fine-grained control flow inside Intel SGX enclaves despite noisy timing measurements and difficult execution control. It develops Intel PT/LBR and APIC-based techniques, demonstrates attacks against SGX applications and security constructs, and proposes hardware and software mitigations.

  • Problem

    Existing timing-based branch-shadowing inference is too noisy for fine-grained control-flow distinction, while practical attacks require precise enclave execution control.

  • Method

    The attack combines Intel PT/LBR branch-history inference with local-APIC timing control, alongside hardware and software countermeasure designs.

  • Results

    The attack extracted sensitive information from SGX applications and bypassed deterministic multiplexing, Sanctum, SGX-Shield, and T-SGX.

  • Takeaways & Limitations

    Branch shadowing can precisely identify basic-block-level enclave control flows, motivating branch-history clearing and branch-oblivious software mitigation.

  • Takeaways & Limitations

    The attack cannot distinguish a not-taken conditional branch from a not-executed one without probing correlated branches.

Abstract

from arXiv · show

In this paper, we explore a new, yet critical, side-channel attack against Intel Software Guard Extension (SGX), called a branch shadowing attack, which can reveal fine-grained control flows (i.e., each branch) of an enclave program running on real SGX hardware. The root cause of this attack is that Intel SGX does not clear the branch history when switching from enclave mode to non-enclave mode, leaving the fine-grained traces to the outside world through a branch-prediction side channel. However, exploiting the channel is not so straightforward in practice because 1) measuring branch prediction/misprediction penalties based on timing is too inaccurate to distinguish fine-grained control-flow changes and 2) it requires sophisticated control over the enclave execution to force its execution to the interesting code blocks. To overcome these challenges, we developed two novel exploitation techniques: 1) Intel PT- and LBR-based history-inferring techniques and 2) APIC-based technique to control the execution of enclave programs in a fine-grained manner. As a result, we could demonstrate our attack by breaking recent security constructs, including ORAM schemes, Sanctum, SGX-Shield, and T-SGX. Not limiting our work to the attack itself, we thoroughly studied the feasibility of hardware-based solutions (e.g., branch history clearing) and also proposed a software-based countermeasure, called Zigzagger, to mitigate the branch shadowing attack in practice.

1 Introduction

The paper introduces branch shadowing, a branch-prediction side-channel attack that exploits uncleared SGX branch history to recover fine-grained enclave control flow. It develops Intel PT/LBR history inference and APIC-based execution control, evaluates attacks and countermeasures, and proposes Zigzagger as a software mitigation.

  • Contribution: Branch shadowing exploits uncleared branch history across SGX enclave-mode switches to reveal taken and not-taken branches and thus fine-grained basic-block execution traces.The attack identifies conditional and indirect branches without noise and unconditional branches with negligible noise.
  • Problem and approach: The attack addresses ASLR, BTB overwriting, and noisy branch-misprediction timing by using a malicious OS to create colliding shadowed branches and by inferring history through processor facilities.The malicious OS can manipulate an enclave process’s virtual address space to create shadowed branch instructions that collide with target branches.
  • Evaluation: Case studies extract sensitive information from SGX SDK, mbed TLS, LIBSVM, and Apache, and analyze protections including ORAM, Sanctum, SGX-Shield, and T-SGX.The evaluated information includes RSA private keys, classification models and parameters, HTTP requests, string conversions, and formatted strings.
  • Contribution: Intel PT and LBR identify branch history, while APIC timer manipulation provides precise execution control and frequent probing inside enclaves.The attack may selectively disable the CPU cache when greater precision is needed.
  • Countermeasures: The paper evaluates hardware- and software-based countermeasures and proposes Zigzagger to mitigate branch shadowing in practice.The countermeasures are presented as proof-of-concept designs.

2 Background

Intel SGX provides enclaves that isolate code and data while exchanging values through untrusted memory. The attack relies on branch-prediction history, LBR records, and APIC timer interrupts to observe and control execution.

  • Intel SGX: SGX provides hardware-based enclaves intended to reduce the trusted computing base to the CPU package, while enclave code exchanges inputs and outputs through untrusted memory.Privileged software such as the operating system and hypervisor is excluded from the intended TCB.
  • Branch Prediction: Dynamic branch prediction uses branch history to predict targets, and changes in prediction behavior can expose a victim process’s activities as a side channel.Processors use stored branch-target information when a branch has a BTB entry.
  • LBR: The LBR records up to 32 recently taken branches on Skylake, including source and target addresses, misprediction status, and elapsed core cycles.LBR operates separately from the instruction pipeline without performance degradation.
  • Local APIC Timer: The local APIC configures CPU-specific interrupts and high-resolution timer interrupts, with periodic, one-shot, and TSC-deadline operating modes.The operating system programs the local APIC through memory-mapped registers or model-specific registers.

3 Branch Shadowing Attacks · 3.1 Threat Model · 3.2 Overview

The branch shadowing attack recovers enclave control flow by probing whether branches are taken and inferring their targets. It assumes an attacker can observe, map, interrupt, and probe the victim enclave’s execution under a compromised operating system.

  • 3 Branch Shadowing Attacks: The attack targets conditional, unconditional, and indirect branches while synchronizing victim and probing code in execution time and memory address space.The attack’s overview explicitly includes three branch types and synchronization requirements.
  • 3.1 Threat Model: The threat model assumes an attacker has compromised the operating system and uses it to attack a target enclave program.This threat model follows Intel SGX and controlled-channel attack assumptions.
  • 3.1 Threat Model: The attacker must know possible branch control flows, including branch instructions and targets, while self-modifying and remotely served code remains out of scope.The attacker can also map the enclave into chosen memory addresses to designate branch and target locations.
  • 3.1 Threat Model: Observable events such as outside-enclave calls and page faults let the attacker infer the victim’s code region and synchronize probing with enclave execution.This synchronization supports the branch probing code described later in the paper.
  • 3.1 Threat Model: The attacker frequently interrupts the enclave to run branch-probing code by manipulating a local APIC timer or disabling the CPU cache.Frequent interruptions enable repeated probing of the victim’s execution.
  • 3.1 Threat Model: Branch probing recognizes prediction or misprediction through hardware performance counters such as the LBR or by measuring branch-misprediction penalties.These observations provide the signal used to distinguish branch outcomes.
  • 3.2 Overview: The attack enumerates victim branches and targets, then uses aligned shadow code whose BPU behavior and execution time reveal whether a victim conditional branch was taken.Figure 1 illustrates that the shadowing instance’s execution time depends on the victim branch outcome.

3.3 Conditional Branch Shadowing

Conditional branch shadowing infers whether an enclave branch was taken by observing whether an aligned shadow branch is predicted correctly or mispredicted. Timing-based detection is unreliable because branch-misprediction penalties are noisy, motivating more precise history-based inference.

  • Conditional branch shadowing: An attacker determines a conditional branch’s outcome by checking whether an aligned shadow branch is correctly predicted or mispredicted.A taken victim branch causes a correct shadow prediction, whereas a non-taken victim branch causes a rollback-inducing misprediction.
  • Conditional branch shadowing: The shadow branch and target must share the victim’s lower 31 address bits to access the same BTB entries.
  • Conditional branch shadowing: The attack interrupts enclave execution, enables branch-history observation, and then executes shadow code whose prediction reflects the victim branch’s prior outcome.The described non-taken case includes OS control before the shadow execution.
  • Conditional branch shadowing: RDTSC-based inference is difficult because branch-misprediction penalties are highly noisy and lack a clear correct-versus-incorrect prediction boundary.The number of instructions mistakenly executed after a misprediction is difficult to predict.

3.4 Unconditional Branch Shadowing

Unconditional branch shadowing reveals enclave instruction-pointer locations and if-else outcomes by detecting branch-target misprediction penalties, since LBR omits these mispredictions. The attack distinguishes executed from unexecuted victim branches using mismatched targets, elapsed-cycle measurements, and LBR inspection.

  • 3.4 Unconditional Branch Shadowing: Unconditional branch shadowing reveals enclave IP locations and if-else condition outcomes from whether target branch history indicates execution.An if block’s final unconditional jump to skip the corresponding else block exposes the condition result.
  • 3.4 Unconditional Branch Shadowing: Because unconditional branches are always taken, the attack must detect target mispredictions rather than ordinary branch mispredictions, which LBR does not report.The authors therefore use elapsed cycles from an LBR-reported branch as a less-noisy proxy than RDTSC, as shown in Table 1.
  • 3.4 Unconditional Branch Shadowing: The attack mismatches shadow and victim targets, then uses an additional branch’s elapsed cycles and LBR retrieval to infer branch-target misprediction.For an executed victim branch, mismatched history causes BPU misprediction, rollback, and a measurable penalty; large elapsed cycles identify the event.
  • 3.4 Unconditional Branch Shadowing: When the victim unconditional branch is not executed, the BTB lacks its information, the shadow branch is correctly predicted, and elapsed cycles remain small.The OS interrupts enclave execution, enables LBR, executes shadow code, and infers no target misprediction from the small elapsed-cycle measurement.
  • 3.4 Unconditional Branch Shadowing: LBR reports every taken unconditional branch as correctly predicted even when BTB collisions cause target misprediction, limiting direct LBR-based detection.The authors attribute this behavior to unconditional branches having fixed targets and therefore generally not being expected to mispredict.

3.5 Indirect Branch Shadowing · 3.6 Frequent Interrupt and Probe

The attack infers whether enclave indirect branches executed by shadowing BTB history and checking branch-target prediction through LBR. Because BTB entries can be overwritten or changed, frequent APIC interrupts and selective cache disabling improve the temporal resolution of probing.

  • 3.5 Indirect Branch Shadowing: Indirect branch shadowing infers enclave execution by setting the shadow branch target to its next instruction and observing whether branch-target misprediction reflects prior history.The procedure uses LBR after executing shadow code to inspect branch information.
  • 3.5 Indirect Branch Shadowing: When the victim indirect branch executes, its taken target is stored in branch history, whereas omitting it leaves no BTB information and allows correct shadow-branch prediction.The paper describes these as separate taken and not-taken cases in the attack procedure.
  • 3.6 Frequent Interrupt and Probe: BTB capacity limits accuracy: Skylake has 4,096 entries in four ways and 1,024 sets, so taking more than 4,096 distinct branches likely overflows history.The paper also notes that address conflicts rarely occurred under the observed index-hashing behavior.
  • 3.5 Indirect Branch Shadowing: The attack infers branch types and states using information from the BTB and/or LBR.Table 2 summarizes the branch types and states covered by the attack and the required information.
  • 3.6 Frequent Interrupt and Probe: Loops or function re-execution can remove or change conditional- or indirect-branch BTB entries, causing the attack to miss branch histories.These execution patterns are identified as a second source of BTB-history disruption.
  • 3.6 Frequent Interrupt and Probe: The authors counter BTB-history disruption by interrupting the enclave frequently through local APIC timer manipulation and checking branch history.The Linux implementation changes the next TSC deadline and invokes attack code from the timer-interrupt handler.
  • 3.6 Frequent Interrupt and Probe: For loops shorter than 50 instructions, selectively disabling the victim core’s L1 and L2 caches increases interruption frequency beyond timer-only probing.The cache-disable bit of CR0 is set through a kernel module, reaching about 4.71 ADD instructions between interrupts before the passage truncates.

3.7 Virtual Address Manipulation

The attack requires manipulating the victim enclave’s virtual addresses, which the attacker achieves after compromising the OS by changing page tables and relocating the enclave base address.

  • 3.7 Virtual Address Manipulation: The attacker disables user-space ASLR and modifies Linux’s Intel SGX driver to change the enclave’s base address, enabling virtual-address manipulation.The assumed OS compromise makes page-table manipulation straightforward; the setup also places an arbitrary number of NOP instructions before the enclave code.

3.8 Attack Synchronization

Attack synchronization scales branch shadowing to large victim enclaves by inferring executed functions and probing only their branches. Special shadow code and, when available, page-fault observations help identify relevant functions or pages, but page-fault synchronization fails against defenses that block the channel.

  • Function-level probing addresses the insufficiency of probing multiple branches per iteration in large victim enclave programs.The attacker first infers executed or currently executing functions, then probes branches belonging to those functions.
  • Externally invoked entry points and functions relying on external calls are identifiable because the operating system can control and observe them.
  • Always-reachable shadow branches let attackers detect execution of non-exported functions and select corresponding shadow code.The branches can be placed at target-function prologues and executed periodically.
  • Page-fault synchronization narrows checking to functions on the code page about to execute, but fails when defenses prevent page-fault side channels.

4 Case Studies

The case studies show that branch shadowing recovers fine-grained control-flow and secret-dependent information from SGX applications even when controlled-channel attacks cannot. It also defeats several software- and hardware-based defenses against page-fault, cache-timing, and related side channels.

  • Linux SGX SDK: Branch shadowing inferred libc inputs and control flow that controlled-channel attacks could not observe, including strtol() sign and length and vfprintf() format strings and variable arguments.These cases involve control flows within a single page and inline functions that produce no informative page-fault sequence.
  • LIBSVM and Apache: The attack recovered application secrets from LIBSVM and Apache, identifying kernel type and vector length, and HTTP methods including GET, POST, DELETE, and PATCH.LIBSVM kernel recognition relies on switch-case control flow, while Apache’s lookup invokes only no function or memcmp(), preventing controlled-channel identification.
  • Defeating SGX defenses: Branch shadowing defeats deterministic multiplexing because branch history distinguishes real from dummy blocks even when page accesses are made indistinguishable.Executing both real and dummy branches, as in Raccoon, is suggested as a possible improvement but is described as difficult.
  • Defeating SGX defenses: T-SGX cannot detect or prevent branch shadowing because the attack recognizes executed basic blocks by probing their branch instructions rather than observing page faults.T-SGX individually wraps basic blocks with Intel TSX and connects them through a springboard page.
  • Defeating SGX defenses: SGX-Shield’s fixed, aligned randomization units and lack of live re-randomization let attackers infer their execution sequence, while Sanctum’s page-fault and cache defenses do not address branch prediction.The attack against Sanctum requires manipulating virtual addresses unless branch-prediction behavior is obfuscated.

5 Countermeasures

The section evaluates hardware-based BTB/BPU flushing and presents Zigzagger, a compiler-based software mitigation that obfuscates branches while limiting performance overhead. Hardware flushing is effective, but Zigzagger offers practical protection when hardware changes are unavailable.

  • Hardware-based countermeasure: Flushing BTB and BPU state at 100K-cycle intervals reduces performance by less than 2%, while flushing every 1 million cycles has negligible impact.The evaluation uses MacSim with SPEC06 traces and models a 4,096-entry, 4-way BTB plus a gshare predictor.
  • Hardware-based countermeasure: At 4GHz, a 100K-cycle flush interval permits 10,000 interrupts per second and is reasonable relative to measured Linux and Windows interrupt rates.The measurements report approximately 250 timer interrupts per second on Linux 4.4 and 1,000 on Windows 10.
  • Software-based countermeasures: Hardware flushing can prevent branch shadowing, but deployed Intel CPUs may lack protection if the changes cannot be delivered through microcode updates.Software alternatives include branch elimination or Raccoon, but CMOV-based branch removal is algorithm-specific and Raccoon incurs 21.8× overhead.
  • Zigzagger: Zigzagger converts branch instructions into unconditional jumps targeting a trampoline that ultimately selects the real target, preventing branch shadowing from revealing taken branches.It uses CMOV to compute targets without conditional jumps and is implemented as an LLVM 4.0 pass.
  • Zigzagger: 1.34× overhead provides full Zigzagger protection, while merging ≤3 branches into one trampoline reduces average overhead below 1.22× on nbench.The implementation reserves r15 and transforms branches through shared trampolines; reserving a register produced a 4%–50% microbenchmark improvement.

6 Discussion

The discussion identifies ambiguity limits that prevent branch shadowing from distinguishing certain branch behaviors and introduces hyperthreaded and blind variants as advanced attacks.

  • Limitations: Branch shadowing cannot distinguish not-taken from not-executed conditional branches, or certain indirect-branch cases with identical predicted targets.Both cases leave the BTB without distinguishing information, while an indirect branch to the right next instruction and a not-executed indirect branch share predicted targets; attackers must therefore probe further.
  • Advanced Attacks: The paper introduces hyperthreaded and blind branch shadowing attacks as advanced attacks derived from the original technique.The hyperthreaded variant exploits BTB entry conflicts between malicious and victim hyperthreads sharing a physical core, given the victim’s address information.

7 Related work

Prior work has explored SGX applications, library operating systems, and the security properties of SGX itself. Researchers have also demonstrated page-fault side channels and proposed mitigations including ORAM-like obfuscation, TSX-based detection, and redesigned enclaves.

  • Intel SGX: SGX research spans secure data analysis, distributed computing, networking services, library operating systems, and intensive study of SGX security properties.Library OSes enable existing applications to run inside enclaves without modification.
  • Intel SGX: Page-fault side-channel attacks manipulate page tables to trigger faults and infer enclave secrets from the resulting page-fault sequence.The cited work describes this as an attack exploiting SGX’s reliance on the operating system for memory resource management.
  • Intel SGX: Proposed defenses include an ORAM-like scheme that obfuscates memory-access patterns but incurs significant performance overhead.This scheme addresses page-fault-based side channels.
  • Intel SGX: Other defenses use Intel TSX to detect suspicious enclave page faults or redesign enclaves to prevent page-fault and cache-timing side channels.These approaches complement access-pattern obfuscation with detection and architectural protection.

8 Conclusion

The paper identifies branch shadowing as a side channel that reveals basic-block-level enclave control flows and proposes hardware and software mitigations.

  • 8 Conclusion: Thorough side-channel analysis is necessary for trusting hardware-based TEEs as secure public-cloud infrastructure.The paper frames incomplete side-channel analysis as a barrier to confidence in TEE security.
  • 8 Conclusion: Branch shadowing precisely identifies fine-grained, basic-block-level control flows executed inside Intel SGX enclaves.The attack exploits side-channel leakage from enclave execution.
  • 8 Conclusion: The paper proposes clearing branch history during enclave mode switches and making branch executions oblivious as complementary countermeasures.The first mitigation is hardware-based, while the second is software-based.
Loading 1611.06952v3…