Slashdot Mirror
Another Day, Another Intel CPU Security Hole: Lazy State (zdnet.com)
Steven J. Vaughan-Nichols, writing for ZDNet: The latest Intel revelation, Lazy FP state restore, can theoretically pull data from your programs, including encryption software, from your computer regardless of your operating system. Like its forebears, this is a speculative execution vulnerability. In an interview, Red Hat Computer Architect Jon Masters explained: "It affects Intel designs similar to variant 3-a of the previous stuff, but it's NOT Meltdown." Still, "it allows the floating point registers to be leaked from another process, but alas that means the same registers as used for crypto, etc." Lazy State does not affect AMD processors.
This vulnerability exists because modern CPUs include many registers (internal memory) that represent the state of each running application. Saving and restoring this state when switching from one application to another takes time. As a performance optimization, this may be done "lazily" (i.e., when needed) and that is where the problem hides. This vulnerability exploits "lazy state restore" by allowing an attacker to obtain information about the activity of other applications, including encryption operations. Further reading: Twitter thread by security researcher Colin Percival, BleepingComputer, and HotHardware.
This vulnerability exists because modern CPUs include many registers (internal memory) that represent the state of each running application. Saving and restoring this state when switching from one application to another takes time. As a performance optimization, this may be done "lazily" (i.e., when needed) and that is where the problem hides. This vulnerability exploits "lazy state restore" by allowing an attacker to obtain information about the activity of other applications, including encryption operations. Further reading: Twitter thread by security researcher Colin Percival, BleepingComputer, and HotHardware.
For some types of chips and applications, perhaps having real security means not being able to do fancy optimizations that degrade security.
I wonder how well typical PC operating systems would work if they were re-compiled to not take advantage of optimizations and run on a completely-de-optimized architecture-compatible CPU with buses, memory, chipsets, etc. that were similarly "de-optimized" and had other things in them like less-tightly-packed circuits to prevent certain side-channel attacks (e.g. rowhammer).
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
This was posted to a blog in 2015:
As someone who worked in an Intel Validation group for SOCs until mid-2014, I can tell you, yes, you will see more CPU bugs from Intel than you have in the past.
Why?
In late in 2013 there were meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: "We need to move faster. Validation is taking much longer than it does for our competition. We need to do whatever we can to reduce those times... we can't live forever in the shadow of the 90's FDIV bug, we need to move on. Our competition is moving much faster than we are." (I'm paraphrasing. )
Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation. That wasn't explicitly said, of course, but that was the implicit message.