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: 11452
Joined: 2004-05-10
It's funny for us , but just imagine the *** the big server farms are going thru week after week that every time they think the patching is over- here we start again...
EPYC becoming more and more attractive for them for next upgrade lol.
These constant security flaws could be the best thing that happened to AMD ever.
Senior Member
Posts: 813
Joined: 2009-11-30
even if already used all the time, until now there no "big-news" whatsoever regarding the exploit that done real-damage to people
for me personally, as long my sensitive-data not used for bad-things that can give me any loss, then no problem whatsoever
like our bank/personal data, say goverment been using the exploit to get all those information, but again for civil people, other than for verification purpose most of time, i dont think they do anything else
not like cyber-thef that use those sensitive data to get money, if this the case indeed everyone should panic.
but i mean its similar to ISP, ur isp might monitoring your usage, but they dont do anything whatsoever right? even say u are downloading tons on piracy-stuff etc.
beside now let say intel fix whole current vulnerability mess, that doesnt mean the CPU will vulnerability-free anyway.... there will always vulnerability, it just matter time before it get exposed
Senior Member
Posts: 150
Joined: 2015-01-12
Another speculative execution vulnerability, what a surprise.. I dont know how intel is going to fix all these since it can be exploided as long speculative execution is working. They should just nuke whole speculative feature and fix it at hardware level.
Senior Member
Posts: 137
Joined: 2016-10-11
And the best thing is that intel got 99% of the market so AMD can watch from the side and learn and improve the product/make patches if needed before launch and offer Secure 7nm EPYC for customers

Senior Member
Posts: 14169
Joined: 2014-07-21
Honestly, I'm still surprised we all didn't get hacked all the years back, you can't tell me nobody tried to exploit such a feature. I'm more thinking I need my tin foil hat again, because so many "different" security issues, flaws and exploits can't be not recognised for a decade in PC business. Somebody has to have known about it, and probably exploited it all the time.