PaperlayerView exact revision on arXiv

Source-linked AI summary

LazyFP: Leaking FPU Register State using Microarchitectural Side-Channels

Julian Stecklina, Thomas Prescher

arXiv:1806.07480v1cs.OScs.ARcs.CR

TL;DR

Lazy FPU context switching avoids saving and restoring register state when a process may not use the FPU, but it leaves that state in place. The paper presents LazyFP, which uses speculative execution and cache side effects to recover FPU and SIMD registers across process and VM boundaries. It argues the optimization is dangerous on affected processors, including for AES-NI use.

  • Problem

    Saving and restoring the expanding FPU and SIMD register set during context switches burdens operating systems, motivating lazy switching that defers the work until register use.

    Source: The x87 FPU · pp. 1–2

  • Method

    LazyFP transiently executes FPU or SIMD instructions after the #NM fault and uses cache side effects to reconstruct register contents.

    Source: INTRODUCTION · p. 1, The One-Bit Leak · p. 3

  • Results

    The paper shows that speculative execution can leak architecturally inaccessible FPU state, and argues that LazyFP significantly weakens AES-NI on vulnerable systems.

    Source: CONCLUSION · p. 5, IMPACT ON AES-NI · p. 5

  • Takeaways & Limitations

    The authors argue lazy FPU context switching is a dangerous optimization when systems may run on affected processors.

    Source: CONCLUSION · p. 5

    The attack assumes the attacker can execute arbitrary user code on the same processor core as the victim; achieving co-location is out of scope.

    Source: LEAKING FPU REGISTERS · p. 2

Abstract

from arXiv · show

Modern processors utilize an increasingly large register set to facilitate efficient floating point and SIMD computation. This large register set is a burden for operating systems, as its content needs to be saved and restored when the operating system context switches between tasks. As an optimization, the operating system can defer the context switch of the FPU and SIMD register set until the first instruction is executed that needs access to these registers. Meanwhile, the old content is left in place with the hope that the current task might not use these registers at all. This optimization is commonly called lazy FPU context switching. To make it possible, a processor offers the ability to toggle the availability of instructions utilizing floating point and SIMD registers. If the instructions are turned off, any attempt of executing them will generate a fault. In this paper, we present an attack that exploits lazy FPU context switching and allows an adversary to recover the FPU and SIMD register set of arbitrary processes or VMs. The attack works on processors that transiently execute FPU or SIMD instructions that follow an instruction generating the fault indicating the first use of FPU or SIMD instructions. On operating systems using lazy FPU context switching, the FPU and SIMD register content of other processes or virtual machines can then be reconstructed via cache side effects. With SIMD registers not only being used for cryptographic computation, but also increasingly for simple operations, such as copying memory, we argue that lazy FPU context switching is a dangerous optimization that needs to be turned off in all operating systems, if there is a chance that they run on affected processors.

INTRODUCTION

The paper introduces a LazyFP vulnerability in which speculative execution can expose FPU register state across process and virtual-machine boundaries. It reports full recovery of a victim’s FPU state using unprivileged local code on a system using lazy FPU context switching.

INTRODUCTION

  • The attack extends research prompted by Meltdown and Spectre into security issues arising from processor microarchitectural design.Source: INTRODUCTION · p. 1
  • LazyFP exploits Intel processors’ behavior after a #NM exception, which operating systems use to implement lazy FPU context switching.The paper frames this as a new information leak vulnerability affecting popular operating systems and hypervisors.Source: INTRODUCTION · p. 1
  • Unprivileged local code can use speculative execution with lazy FPU context switching to recover a victim process’s full FPU register state.The paper identifies cryptographic keys as an example of confidential information held in FPU registers.Source: INTRODUCTION · p. 1

The x87 FPU

Lazy FPU context switching was designed to avoid the cost of saving and restoring FPU state when a process does not use it. The section explains its #NM-based ownership mechanism and why widespread SIMD use weakens the assumption behind that optimization.

The x87 FPU

  • Saving and restoring FPU state on every context switch imposed unnecessary overhead when many processes did not use the FPU.The x87 FPU has its own instructions and registers; its state must be managed for multitasking.Source: The x87 FPU · p. 1
  • Lazy FPU context switching leaves the state in place and switches it only when necessary, avoiding saves and restores for processes that do not use the FPU.Source: The x87 FPU · p. 2
  • After a process switch, the OS disables the FPU; an #NM exception lets it re-enable the FPU for its owner or save and restore state for a new owner.The OS tracks which process owns the current FPU register state.Source: The x87 FPU · p. 2
  • SSE, AVX, and AVX-512 expanded FPU state, while mandatory SSE and common uses such as memory copying mean processes eventually touch FPU registers.Linux switched to eager FPU context switching by default, so normal operation does not generate an #NM exception.Source: The x87 FPU · p. 2

FPU Handling in Virtualized Systems

Under Intel VT, the hypervisor—not the processor—handles FPU register-state switching between guest mode and the hypervisor, using mechanisms like those in a non-virtualized operating system.

FPU Handling in Virtualized Systems

Speculative Execution

Speculative execution can leave microarchitectural traces even when transient instructions do not commit architectural effects. The section also defines Intel TSX and states the attack’s same-core execution assumption.

Speculative Execution

  • Transient instructions whose architectural effects are discarded can still change microarchitectural state, such as cache contents.Speculation executes ahead of time while the processor awaits information such as a branch outcome or whether an instruction raises an exception.Source: Speculative Execution · p. 2

Intel TSX

  • In this paper, Intel TSX refers specifically to Restricted Transactional Memory (RTM), one of the two extensions under the TSX product name.RTM provides instructions for transactional code regions that may be rolled back on an error or concurrent access.Source: Intel TSX · p. 2

LEAKING FPU REGISTERS

  • The attack assumes a victim with confidential FPU data and an attacker able to run arbitrary user code on the same processor core.How to achieve co-location is out of scope; random chance may suffice, and pinning threads to cores is typically not privileged.Source: LEAKING FPU REGISTERS · pp. 2–3

The One-Bit Leak

The one-bit leak maps an FPU register bit to a cache-line access, then probes that cache effect after speculative execution with the previous process’s register state.

The One-Bit Leak

  • The code masks bit 0 of xmm0 and shifts it by 6, selecting one of two cache lines on a system with 64-byte cache lines.The shown instructions then write to the selected location.Source: The One-Bit Leak · p. 3
  • The FPU access executes speculatively with the previous process’s register set before the kernel handles the resulting #NM exception and retries execution.The speculative instructions’ architectural changes are discarded, but their cache footprint remains.Source: The One-Bit Leak · p. 3, Figure 1
  • After setting the attacker’s xmm0 to zero and flushing the second line, the attacker probes its access latency to recover the victim’s bit.The victim must run before each attempt to regain FPU ownership, potentially changing the register contents.Source: The One-Bit Leak · p. 3

Leaking the Complete Register Set

A page fault can keep the victim’s FPU state in place while the attacker probes it repeatedly, but signal handling adds noise to the cache measurement.

Leaking the Complete Register Set

  • The attacker triggers a page fault before the FPU access and configures a signal handler to recover rather than abort.The FPU access then occurs only speculatively, so its #NM exception is not generated.Source: Leaking the Complete Register Set · p. 3
  • Because the operating system does not handle #NM, it does not replace the victim’s FPU register state, allowing the attacker to continue probing further bits.The page-faulting instruction’s subsequent speculative results are discarded when it retires.Source: Leaking the Complete Register Set · p. 3, Figure 2 · p. 3
  • Signal handling can evict the cache line brought in by speculative execution, adding noise before the attacker observes the cache effects.Source: Leaking the Complete Register Set · p. 3

Suppressing Exceptions using Intel TSX

The paper presents TSX and Retpoline as ways to suppress the #NM exception during speculative FPU access. Retpoline also works on older processors without TSX support and is reported as slightly faster.

Suppressing Exceptions using Intel TSX

  • RTM transactions abort on exceptions, letting the attacker leak one bit without triggering operating-system exception handling.The attack executes inside a TSX transaction, with subsequent instructions already executed speculatively when #NM causes the abort.Source: Suppressing Exceptions using Intel TSX · p. 3, Figure 3 · p. 3

Suppressing Exceptions using Retpoline

  • TSX limits the attack to recent processors, while Retpoline can provide similar exception suppression on older processors without TSX.The passage dates TSX support from Haswell onward.Source: Suppressing Exceptions using Retpoline · pp. 3–4
  • Retpoline captures speculative execution in a pause loop by making the RSB prediction differ from the return address in memory.A return follows the RSB prediction speculatively until the actual return address is fetched and the misprediction is detected.Source: Suppressing Exceptions using Retpoline · p. 4
  • Prepending the FPU access to Retpoline’s capture loop makes that access speculative; the pause loop also keeps execution from reaching the latency-probing code too soon.The authors report this variant is applicable without TSX and slightly faster than the TSX variant.Source: Suppressing Exceptions using Retpoline · p. 4

EVALUATION

On the tested system, page-fault suppression was much slower than TSX or Retpoline. The latter methods could leak a complete register-state snapshot within one scheduling time slice, including for AVX-512.

EVALUATION

  • More than 300000 cycles, or 138 µs, were required to leak one 256-bit AVX register with the page-fault method.The evaluation used an Intel Core i7-5600U at 2.60 GHz with FreeBSD 11.1; victim and attacker were pinned to the same logical CPU.Source: EVALUATION · p. 4
  • Intel TSX and Retpoline increased leakage efficiency by an order of magnitude over the page-fault method.Source: EVALUATION · p. 4
  • TSX and Retpoline could leak a complete FPU register-state snapshot within one scheduling time slice, even for AVX-512 register files.The paper notes that 4 bits per attempt would quadruple the side-channel’s effective throughput.Source: EVALUATION · p. 4

IMPACT ON AES-NI

AES-NI implementations that keep key material in SSE registers are exposed to LazyFP on affected systems. The paper concludes that documented AES-NI use cannot provide confidentiality there, while avoiding AES-NI re-enables earlier side-channel attacks.

IMPACT ON AES-NI

  • AES-NI provides hardware acceleration for AES and is widely used for efficient implementations.Source: IMPACT ON AES-NI · p. 5
  • AES-NI cannot provide confidentiality on affected systems when used as Intel documents suggest: required round keys reside in SSE registers within LazyFP’s reach.An attacker able to execute code on the same system can reach them regardless of privileges.Source: IMPACT ON AES-NI · p. 5, Figure 6 · p. 5
  • The AES-NI key-expansion example keeps the original cipher key in an SSE register for an extended period.Source: IMPACT ON AES-NI · p. 5
  • Avoiding AES-NI on affected systems is not an effective mitigation, because it re-enables earlier timing and cache-based attacks.Source: IMPACT ON AES-NI · p. 5

MITIGATION

The paper recommends replacing lazy FPU context switching with eager switching, including a configurable Linux boot option. It relates LazyFP to prior transient-execution work and describes TSX exception masking and a Retpoline-inspired technique as attack building blocks.

MITIGATION

  • Eager FPU context switching is the long-term mitigation; configurable systems can enable it, including Linux kernels newer than 3.7 with “eagerfpu=on”.For most operating systems without a configuration option, the change must be implemented by the vendor.Source: MITIGATION · p. 5

RELATED WORK

  • LazyFP extends Meltdown and Spectre’s microarchitectural attacks on sensitive memory to sensitive information in the FPU register set.Source: RELATED WORK · p. 5
  • The attack uses TSX to mask exceptions and a Retpoline-inspired technique for high-performance exception suppression and speculative-execution steering.Source: RELATED WORK · p. 5

CONCLUSION

The paper demonstrates speculative leakage of architecturally inaccessible FPU state on Intel x86, including SIMD registers used for cryptography, and argues that AES-NI is weakened on vulnerable systems. The authors report responsible disclosure to Intel in February 2018 and identify CVE-2018-3665.

CONCLUSION

  • Speculative execution can leak architecturally inaccessible FPU register state on Intel x86 processors, including SIMD registers widely used for cryptography.Source: CONCLUSION · p. 5
  • AES-NI is significantly weakened when executed on a system vulnerable to LazyFP.Source: CONCLUSION · p. 5

RESPONSIBLE DISCLOSURE

  • The authors disclosed the vulnerability to Intel in February 2018; it was assigned CVE-2018-3665 and published as INTEL-SA-00145.The authors also report receiving an Intel bug bounty.Source: RESPONSIBLE DISCLOSURE · p. 5
Loading 1806.07480v1…