New Vulnerability hits Intel processors - Lazy FP State Restore
Yet another security vulnerability was found in Intel chips and affects the processor's speculative execution technology, much like Spectre and Meltdown. It can potentially be exploited to access sensitive information, including encryption related data.
The news was just posted at Intel, we'll follow the explanation from Red Hat though; Exploitation of lazy floating point restore could allow an attacker to obtain information about the activity of other applications, including encryption operations. The underlying vulnerability affects CPU speculative execution similar to other recent side-channel vulnerabilities. In this latest vulnerability, one process is able to read the floating point registers of other processes being lazily restored.
Root Cause - Lazy save/restore of FPU/SSE/AVX States:
Modern processors employ numerous techniques to improve system performance. One such technique is to defer save and restore of certain CPU context states on task switch. Today, processors come equipped with a dedicated Floating Point Unit (FPU) to perform high precision floating-point operations used in scientific, engineering and/or graphics applications. The FPU maintains its own context state in its data registers, status registers, as well as control and opcode registers.
A task/context switch occurs when a user application calls a kernel function or when a process is preempted to schedule the next one in the queue. Upon a task switch, the processor saves its current execution context (various registers, instruction and stack pointers, etc.) and loads the context of the new process. While doing so, it can defer restoring of FPU/SSE context state, because not all applications use the Floating Point Unit (FPU). If the newly scheduled process does not use Floating-Point (FP) instructions, it does not need to save/restore FPU context state. This can save precious execution cycles and improves performance.
Under the lazy restore scheme, during 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. In other words, loading of the FPU state is deferred until an FP instruction is invoked by the current task - Lazy FPU restore.
Recent processors include processor extensions (“XSAVEOPT”) that implement FPU restore in hardware more efficiently, giving the performance benefits of lazy FPU without having to rely on the DNA exception. On these processors, Red Hat Enterprise Linux 7 is already using eager FPU restore, and is therefore not vulnerable.
Impact
A newly scheduled task can use the exploit described herein to infer the Floating Point register state of another task, which can be used to leak sensitive information.
Senior Member
Posts: 13379
Joined: 2003-05-24
yep, everyone wants there day in the news. majority of public is never gone keep up with let alone patches this stuff I still have yet to do the bios patches for original issue. it will be cold day in hell before i play this update my bios every 3 weeks people need to learn to keep there mouths zipped about this stuff. and lets this stuff be slightly fixed in hw instead cause panic in the public.
Senior Member
Posts: 1690
Joined: 2012-10-07
Like others have said, Intel really need to fix all these speculative side channel vulnerabilities in hardware - to improve security & also their reputation, but I do wonder how much performance they will have to sacrifice in their next hardware-fixed chips to make that happen. We may never know the answer to that though, because there'd be no basis for comparison when it comes to said new chips. I'm fed up with hearing about it - sure I'm gonna keep reading the news on it, but I am fed up with it, thinking do I need to patch this or do I need to patch that, what's the performance hit gonna be, etc. At the moment I use Spectre-fixed microcode on my Skylake desktop, then use InSpectre program to flip protection on or off depending on what I'm doing - gaming I switch it off, everything else I leave the protection on - just requires a reboot to make the switch. I'd rather not bother messing about with it, bring on the hardware fixes!
Senior Member
Posts: 7158
Joined: 2012-11-10
That, and cryptocurrency miners.
Senior Member
Posts: 2479
Joined: 2010-05-26
I'm seriously starting to think a lot of these "exploits" might of been intentional. Maybe not all of them but some of them might of been forced in there by CIA/Mossad/Mi6. So they could be used in any future wars or to gain access to top secret files when the need arises. They were always there waiting for bad actors to exploit but now the public is witch hunting any and every tiny crack until the chips themselves will be useless.
Could also be a ploy to force people on to the next secure platform. ^^
Senior Member
Posts: 3927
Joined: 2011-11-24
Hm. XSAVEOPT was introduced with Sandy Bridge. So does that mean the vulnerability affects only CPUs older than SB?