Lazy FPU X86 Flaw Hits Intel Processors With Yet Another Major Security Vulnerability

core i9 chips
A newly discovered security vulnerability in modern Intel X86 processors has been revealed that affects the processor's speculative execution technology – like Spectre and Meltdown – and can be used to access sensitive information, including encryption related data. Over the last day or two, patches have quietly rolled out for some operation systems, but Red Hat just revealed all of the underlying details. The vulnerability, which is being called "Lazy FPU Save/Restore," was assigned a moderate rating and an ID of CVE-2018-3665 in the company's solutions database.

As its name suggests, the exploit leverages the processor's FPU's (Floating Point Unit) "lazy state restore" feature in Intel Sandy Bridge and newer CPUs; according to the listing on Red Hat. However, AMD processors are not affected by this flaw.

“CVE-2018-3665, also known as Floating Point Lazy State Save/Restore, is another speculative execution vulnerability that affects some commonly deployed modern microprocessors”, said Jon Masters, Computer Architect, Red Hat. “Red Hat is collaborating with our industry partners on optimized mitigation patches, which will be available via our normal software release mechanism. Red Hat is also providing guidance to our customers about shorter term mitigation options. We continue to work closely with our peers and security researchers, encouraging all organizations to follow the industry practice of coordinated disclosure.”
chip in socket
Internal memory registers in modern processors store data about the state of each running application. The state of an application must be saved and restored when switching from one application to another, which can burn a few CPU cycles. To optimize performance, the save or restore of an FPU state may be done “lazily” as Red Hat puts it, which means it’s done only when absolutely necessary. The vulnerability exploits the "lazy state restore" in FPU, SSE, and AVX states in Intel processors. According to Red Hat, “…during a task switch, the first FP instruction executed by a process generates a “Device not Available (DNA)” exception; the DNA exception handler then saves the current FPU context into the old task’s state save area and loads the new FPU context for the current process”. 

A newly scheduled task can then leverage the exploit to infer the FP register state of another task, and access sensitive user information that would normally be protected. In short, it smells a lot like Spectre but from a different threat vector with respect to the FPU, or Floating Point Unit on board the processor. And again, AMD processor are not affected by this, reportedly.

To mitigate the issue, the latest versions of Red Hat Linux will automatically default to a safer “eager” floating point register restore mode on Sandy Bridge and newer Intel processors. The eager FPU restore mode forces the state to be saved and restored for every task/context switch, whether the current process invokes FPU instructions or not.

Red Hat claims enabling eager FPU modes does not negatively impact performance and can be applied with no adverse effects to processors that are not affected. How it affects performance on processors that employ this speculative execution method, or if it affects other operating systems, isn’t yet clear, however. More details to follow as we continue coverage of this new security flaw.

Update, 11:40 PM 6/13/18:  Intel just reached out to us with the following statement on this report:
"The Lazy FP state restore issue is similar to Variant 3a. It has already been addressed for many years by operating system and hypervisor software used in many client and data center products. Our industry partners are working on software updates to address the issue for the remaining impacted environments and we expect these updates to be available in the coming weeks. We continue to believe in coordinated disclosure and we are thankful to Julian Stecklina from Amazon Germany, Thomas Prescher from Cyberus Technology GmbH, Zdenek Sojka from SYSGO AG, and Colin Percival for reporting this issue to us."

An Intel spokesperson also added, "the patches are not expected to negatively impact performance."