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.
AMD should be dumping money right now. Making all this as public as possible and pushing its own CPU's Go AMD go!
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.
nope. Meltdown was an Intel exclusive. Both AMD and Intel run speculative code, but the difference is AMD checked privileges before running speculative code. Intel checked AFTER running it -- meaning unauthorized code could be run before being cleared. That means AMD took a performance hit, but Intel had all kinds of info left in the cache that shouldn't be there so other processes could snoop on things that they shouldn't have privileges to access -- possibly passwords, memory locations, file locations, output for programs that should not have had authorization to run, etc.
Intel's work-around was to clear the cache whenever switching between code of different privileges. That's right -- they dump the cache memory every time a program accesses something of a higher security level so that there's nothing there for a rogue program to access something that's not on its same security level. Side effect being that an empty cache has to be refilled to properly speed up the CPU operations. Things that don't switch much aren't affected much, but some things are severely impacted.
Intel intends to fix this in a few years by changing the silicon to check FIRST -- like AMD does. It takes 2-3 years to design a new processor, though... and I doubt they'll get it in the 2019 silicon. Supposedly, they'll have a quick fix for 2019 silicon and a proper fix for 2020/2021, but who knows. They have been suffering from manufacturing delays b/c they're trying to squeeze the most the can out of outdated lithography and are getting high defects. My bet is the fixes will come when they jump to 7 nm.