After Meltdown (see also our article about Meltdown) and Spectre, which were publicly disclosed in January, the Spectre V3a and V4 vulnerabilities followed in May (see also our article about Spectre V4). According to the German IT news publisher Heise, the latter might be part of 8 new vulnerabilities in total that are going to be disclosed in the course of the year.
Earlier this year, Julian Stecklina (Amazon) and Thomas Prescher (Cyberus Technology) jointly discovered and responsibly disclosed another vulnerability that might be part of these, and we call it LazyFP. LazyFP (CVE-2018-3665) is an attack targeting operating systems that use lazy FPU switching. This article describes what this attack means, outlines how it can be mitigated and how it actually works.
For further details, see the current draft of the lazyFP paper: Link to Paper
Summary and Implications
The public disclosure of this vulnerability was initially postponed by a typical responsible disclosure information embargo until August, but first rumors led to this date being dropped.
The register state of the floating point unit (FPU), which consists of the AVX, MMX and SSE register sets, can be leaked across protection domain boundaries. This includes leaking across process- and virtual machine boundaries.
The FPU state may contain sensitive information such as cryptographic keys. As an example, the Intel AES instruction set (AES-NI) uses FPU registers to store round keys. It is only possible to exploit when the underlying operating system or hypervisor uses lazy FPU switching.
Another interesting use case of this vulnerability is building high-performance covert channels between VMs. When using all register sets and controlling the scheduling frequency of the core, it is possible to maximize the throughput up to the range of MB/s.
Users are affected when they run a combination of affected processor and affected operating systems.
- Affected operating systems:
- kernel versions < 4.9 with non-default boot parameters
eagerfpu=off) are affected
- kernel versions < 4.6 running on affected Intel CPUs prior to Haswell
or with custom boot parameters (
- kernel versions 4.4.y with y < 138 have a bug in their eager FPU switching
- kernel versions < 3.7 on all affected CPUs
- kernel Linux versions starting with 4.9 are not affected irrespective of the CPU.
- kernel versions < 4.9 with non-default boot parameters (
- Microsoft, see advisory ADV180016
- Affected hypervisors:
- KVM when run on affected Linux kernel versions
- All Xen versions and generally all hypervisors that employ lazy FPU switching
- Affected CPUs when affected operating system or hypervisor is used:
Mitigation requires system software to use eager FPU switching instead of lazy FPU switching.
If you have any questions about the variants of Meltdown and Spectre and their impact or the involvement of Cyberus Technology GmbH, please contact:
Tel +49 152 3429 2889
This vulnerability is similar to Meltdown (CVE-2017-5754). While Meltdown allowed to read protected memory contents from a user space program, this new attack allows to read certain register contents across protection domain boundaries.
In order to exploit the vulnerability, the attacker accesses FPU registers that he is not allowed to access yet. This forbidden value is fed into an address calculation which is used for a subsequent memory access. The CPU will perform this series of instructions speculatively, that is the corresponding register content is squashed when it detects its mistake.
Then, he attempts to read/write from/to a memory address that contains the forbidden register value as part of its address offset. The CPU will speculatively perform this series of loads and stores, but then detect and fix its mistake. This speculative execution however leaves traces in the cache which can leak hidden information to the attacker.
To have a better understanding of how this attack actually works, it is necessary to dive deeper into the inner workings of the FPU, and how it is used by operating systems.
The Floating Point Unit (FPU)
In the early days of x86, the FPU (also called math coprocessor) was an external co-processor that could be added to Intel’s now widely adopted x86 processor architecture. The Intel 8087 was the first floating point math co-processor of this kind. The purpose of this extension was to accelerate mathematical operations on floating point numbers, such as division and multiplication. With the Intel 486DX CPU model (released in 1989), the FPU got integrated into the microchip itself. This way, no additional co-processor was needed anymore.
Over the years, the processor was extended to support Single Instruction, Multiple Data (SIMD) instruction sets, i.e. MMX/SSE/AVX. SIMD instructions perform the same mathematical operation on multiple pairs of operands at the same time in order to improve performance. Each of these instruction set extensions introduced new register sets that continue to be managed as part of the FPU register state. On recent Intel processors, the FPU register state can contain more than 2 kB of data (AVX-512 offers 32 registers of 512 bit, each, which translates into 2 kB additional processor state). Due to the usefulness of these instructions this register set may contain not only floating point values but also other data as e.g. integer values.
Loading and Storing the FPU state
To enable multi-tasking, operating systems periodically interrupt processes to give other processes a chance to run. Otherwise a single process that loops forever could grind the system to a halt.
When the operating system switches from one process to another, it needs to save the state of the previous process and restore the state of the process that is about to be run. This state consists of the values stored in general purpose registers and FPU registers.
The x86 instruction architecture provides several instructions to load/store the register state of the FPU from/to memory. We already know about the large size of the FPU state, hence it is pretty obvious that one does not want to read and write such amounts of data on every context switch unless it is actually necessary, because not all processes use the FPU.
Eager and Lazy FPU Switching
Eager FPU switching is comparable to saving the general purpose register state on a context switch. For each process, the operating system reserves an area in memory to save the FPU state. When switching from one process to another, it executes an FPU store instruction to transfer the current FPU content to the state save area. It then loads the new FPU state from the state save area of the process that is about to be scheduled.
Lazy FPU switching optimizes this procedure for the case where not every process uses the FPU all the time.
After a context switch, the FPU is disabled until it is first used. Only then, the old FPU state will be saved, and the correct one restored from memory. Up to this point, the FPU keeps the register state of the process or VM that used it last.
To implement this optimization, the operating system kernel
temporarily disables the FPU by setting a certain control register bit
CR0.TS). If this bit is set, any attempt to access the FPU
will cause an exception (
#NM, Device Not Available, No
Math Coprocessor). When the exception occurs, the kernel can save
the old state to the respective state area and restore the state of the
current process. Processes that simply do not use the FPU will never
trigger this exception and hence never trigger FPU state stores and
Starting with the introducton of the x86-64 architecture, the presence of at least some SIMD instruction set extensions is mandated and their use has become more widespread. As such the underlying assumption of lazy FPU switching is not valid anymore. The performance gain by lazy FPU switching has become negligible, and some kernels already removed it in favor of eager switching.
The attack works by reading the FPU register contents while the FPU is disabled and disclosing the contents via a cache-based side-channel. At this point, the FPU contains register content of the last process that used it.
To make this attack practical, it is necessary to hide the exception that would normally happen when accessing the FPU. We found three different ways to do so:
Method 1: Executing the attack in the shadow of a pagefault
All of the three versions work similarly. A simplified pagefault version could look like this:
mov dword , 0 ; trigger a pagefault movq rax, xmm0 ; read content of xmm0, would trigger #NM and rax, 1 ; mask bit 0 shl rax, 6 ; align to cache line mov dword [mem + rax], 0 ; access "mem" with offset depending on xmm0 content
The trick here is that the
#NM exception never occurs,
because the instruction that touches the
xmm0 FPU register
is only speculatively executed. Yet, the memory location that is touched
depends on the value of
xmm0 and this value can be
recovered using the same flush-and-reload attack that is also used in
Meltdown and Spectre.
mem is just an ordinary memory buffer
that is accessible to the application. At this point, we are back to the
initial state and can retry the attack to leak the entire register state
bit by bit (always masking a different bit in the
of the code snippet).
Please note that the sample code in this article just reads a single bit for the sake of simplicity. Our proof of concept reads multiple bytes at the same time in order to further reduce the size of the required time window.
Method 2: Executing the attack in a transactional memory (TSX) transaction
The TSX version works in the same way.
With TSX it is possible to perform multiple reads and writes from/to memory within a transaction, which fails if the affected memory cells were modified from elsewhere during the transaction, or if any kind of protection violation occured. The hardware rolls back the changes of the transaction that failed and signalizes this in a way much cheaper than a page fault.
The key difference is that the
#NM exception is
generated inside a hardware transaction (RTM) which is always aborted by
#NM. This version leaks the desired register
content much faster as it removes the expensive pagefault handling from
the execution path.
Method 3: Executing the attack in the shadow of a branch / Retpoline
#NM exception in the shadow of a mispredicted
branch as suggested in this
article about the microarchitectural details is even faster because
no recovery path is needed at all.
“Hiding in the shadow of a mispredicted branch” means that the attack
code would tamper with the return address on the stack, which sabotages
the CPU’s branch prediction efforts for the next return instruction.
Code that is then executed based on such induced wrong speculation will
successfully trigger the sidechannel without causing
The practicability of the attack varies across the different methods to employ it: The attacker needs a time window where no interruption by the operating system occurs in order to read all bits of the register, because every preemption has the chance to change the register state and render the result useless. Thus, the faster the attack method is the more likely it is successful.
|Page fault||359.9k||0.22 MiB/s|
|Intel TSX||25.4k||3.12 MiB/s|
Using GNU/Linux with kernel versions >= 3.7, this attack can be
mitigated by adding “
eagerfpu=on” to the kernel’s boot
parameters. We are not aware of a workaround for older versions. For all
other operating systems: install the official update(s) from the
We are not aware of a performance penalty caused by using eager FPU switching. The commit message of the Linux kernel patch that made eager FPU switching the default on Linux systems even points out that the assumptions which justified lazy FPU switching in the past do not hold any longer on the majority of modern systems.