Lazy FP state restore

The floating point and SIMD registers are large, and not used by every task (or thread) in the system. To make context switching faster, most common microprocessors support lazy state switching. Rather than storing the full state during a context switch, the operating system can simply mark the FPU "not available" in the hopes that the switched-to task will not need it. If the operating system has guessed correctly, time is saved. If the guess is wrong, the first FPU or SIMD instruction will cause a trap to the operating system, which can then save the state to the previous task and load the correct state for the current task.

In out-of-order CPUs, the "FPU not available" condition is not detected immediately. (In fact, it almost cannot be detected immediately, as there may be multiple fault-causing instructions executing simultaneously and the processor must take the first fault encountered to preserve the illusion of in-order execution. The information about which is first is not available until the in-order retire stage.) The processor speculatively executes the instruction using the previous task's register contents, and some following instructions, and only later detects the FPU not available condition. Although all architectural state is reverted to the beginning of the faulting instruction, it is possible to use part of the FPU state as the address in a memory load, triggering a load into the processor's cache. Exploitation then follows the same pattern as all Spectre-family vulnerabilities: as the cache state is not architectural state (the cache only affect speed, not correctness), the cache load is not undone and the address, including part of the previous task's register state, can later be detected by measuring the time taken to access different memory addresses.

It is possible to exploit this bug without actually triggering any operating system traps. By placing the FPU access in the shadow of a forced branch misprediction (e.g. using a retpoline) the processor will still speculatively execute the code, but will rewind to the mispredicted branch and never actually execute the operating system trap. This allows the attack to be rapidly repeated, quickly reading out the entire FPU and SIMD register state.

It is possible to mitigate the vulnerability at the operating system and hypervisor levels by always restoring the FPU state when switching process contexts.[6] With such a fix, no firmware upgrade is required. Some operating systems already did not lazily restore the FPU registers by default, protecting those operating systems on affected hardware platforms, even if the underlying hardware issue existed.[6] On Linux operating system using kernel 3.7 or higher, it is possible to force the kernel to eagerly restore the FPU registers by using the eagerfpu=on kernel parameter.[3] Also, many system software vendors and projects, including Linux distributions,[7] OpenBSD,[8] and Xen[4] have released patches to address the vulnerability.

• Transient execution CPU vulnerabilities

• LazyFP: Leaking FPU Register State using Microarchitectural Side-Channel, by Julian Stecklina and Thomas Prescher (Research paper)
• Intel LazyFP vulnerability: Exploiting lazy FPU state switching, by Thomas Prescher, Julian Stecklina and Jacek Galowicz (Cyberus Technology)
• Lazy FP state restore (Intel Security Advisory)
• Theo de Raadt of OpenBSD explains Lazy FPU state vulnerability on YouTube