CVE-2018-3665: Lazy State Save/Restore As The Latest CPU Speculative Execution Issue

The latest speculative execution vulnerability affecting modern CPUs has now been made public: Lazy State Save/Restore, a.k.a. CVE-2018-3665.

This vulnerability concerns saving/restore state when switching between applications. The newly-disclosed vulnerability exploits lazy-state restores for floating-point state when context switching, which is done as a performance optimization, to obtain information about the activity of other applications on the system.

x86 has a hardware mechanism for lazy FPU context switching. On a task switch, %cr0.ts (Task Switched) gets set, and the next instruction to touch floating point state raises an #NM (No Math, later known as Device Not Available) exception.

Traditionally, FPU state has been large in comparison to available bandwidth (and therefore slow to switch) and not used as frequently as cpu tasks tend to switch. This mechanism allows the OS to only switch FPU when necessary, which in turn increases performance.

Some CPUs however speculate past an #NM exception, allowing register content to be leaked by a side-channel.

This vulnerability is what BSDs like OpenBSD and DragonFlyBSD began patching against last week.

Mitigating this lazy state save/restore vulnerability does not require CPU microcode updates, but does require updated kernel patches. Those on RHEL7 for instance though already default to safe floating point restores on Intel 64-bit CPUs of the past several years that support the XSAVEOPT extension. Hypervisor patches are also needed for VM users.

This vulnerability currently appears to only affect Intel Core (Nehalem and newer) CPUs.

As of writing this article, CVE-2018-3665 hasn't yet been made public and we have just been supplied with limited details so far, so check back for updates as more information gets cleared.

Update: Additional information is now available here via the researchers that uncovered the issue. It looks like recent Linux kernel users where eagerfpu defaults to enabled by default are covered. Additionally, the performance impact of that default kernel change was expected to cause no major performance hit, though I'll run some eagerfpu comparison benchmark runs with the latest kernel to see how it performs (that change happened back in 2016).