Monday, May 3rd 2021
New Spectre Vulnerability Version Beats All Mitigations, Performance to Badly Degrade After the Fix
Researches from the University of Virginia and University of California San Diego have published their latest case study. The two universities have worked hard to discover a new Spectre vulnerability variant that can pass all of the existing Spectre mitigations and exploit all of the existing processors coming from Intel and AMD. The vulnerability exploits all of the existing x86 processors, and as it is new, there are not implementations of hardware mitigation. The whitepaper called "I see dead μops" takes the implementation of exploiting micro-op caches that could lead to a potential data leak in the processor, which is leading to a Spectre-type exploit.
Modern x86 processors break down complex instructions into smaller RISC-like units called micro-ops, in the frontend, where it makes the design of the backend part much simpler. The micro-ops are stored in the micro-ops cache. The paper is describing micro-op cache-based timing channel exploits in three primary settings: "a) across code regions within the same thread, but operating at different privilege levels, (b) across different co-located threads running simultaneously on different SMT contexts (logical cores) within the same physical core, and (c) two transient execution attack variants that leverage the micro-op cache to leak transiently accessed secrets, bypassing several existing hardware and software-based mitigations, including Intel's recommended LFENCE."
For more details about the ways of exploiting the data, it is recommended to read the paper in full. However, if you are wondering about the possible mitigations of this exploit, there could be some bad news regarding performance. Both Intel and AMD have been informed about the attack, and the solution is coming our way. However, since the exploit targets a low-level caching structure, a possible solution would take a severe degradation of performance, as believed by researchers. Maybe Intel and AMD find a solution that is not as severe, but rather a modest one. We must wait to find out.
Sources:
I See Dead μops Paper, via forum member P4-630 (Thanks for the tip!)
Modern x86 processors break down complex instructions into smaller RISC-like units called micro-ops, in the frontend, where it makes the design of the backend part much simpler. The micro-ops are stored in the micro-ops cache. The paper is describing micro-op cache-based timing channel exploits in three primary settings: "a) across code regions within the same thread, but operating at different privilege levels, (b) across different co-located threads running simultaneously on different SMT contexts (logical cores) within the same physical core, and (c) two transient execution attack variants that leverage the micro-op cache to leak transiently accessed secrets, bypassing several existing hardware and software-based mitigations, including Intel's recommended LFENCE."
77 Comments on New Spectre Vulnerability Version Beats All Mitigations, Performance to Badly Degrade After the Fix
What really makes it not noteworthy is the attack is slow and guessing memory locations hard. It requires a lot of setup, and generally, a skilled human hacker.
But not "local access."
If it's a video game, have fun with that.No my point is physical access is NOT required. They are being dismissive of this, which is valid in some ways, but for an invalid reason.
They are also intel funded, which might explain the vagueness of other chips used or just theoretically vulnerable.
In general, yet another poorly done "security piece" not learning from other groups stumbles or intentional misdirection's.
No CVE, no 90 days given to architecture owners, no credibility. I don't see any proof they tested against mitigated hardware.
At the end of the day the software side needs to live up to a certain standard of security as well, if that doesn't happen you will never be able to make a computer that is both fast and versatile while being secure.
If you are completely anal about security then you will have to sacrifice either speed or versatility, and you will have to control the software and runtime environment well.Say bye to your performance then, because now you are going back to the early 2000s where you are 100% guaranteed that your back end is grossly underutilised.
The whole idea of resource sharing is that you can dynamically allocate resources to whatever needs it most. Sure if you can create a runtime where from the getgo you know how much resources each task will need there is no need for dynamic allocation, but good luck convincing any programmer to do that.
Static scheduling and partitioning has proven time and time again to go against what programmers want, else IA-64 wouldn't be left in a ditch and everything would be VLIW...
I'll shutup until I read get home and can read it properly.
Regardless, @efikkan you also mentioned disabling SMT. Now look at the current marketplace :D Say an enterprise disables that for its server farm. Suddenly you have a capacity problem and there is no supplier to build you another bunch of servers. And you're already under pressure because of supply issues in a normal cycle for hardware. Its a rock and a hard place, and there is really never enough time as it is. Fast and some collateral is always going to win the day over slow and careful.
Hint: They are... you guys!
I don't have much to complain about, though. So far, the issues I had in the last 5 years, that I could consider rather grave, I could probably count them with one or two hands. Not exactly a lot.
Definitely not as much as other people say they have had.
The risk/effort balance has to be right, and you can't ever stop everything. If this vulnerability requires direct physical access then it's of no consequence to any consumer device. Even thinking about my servers in a colo datacenter, the amount of ID checking and paperwork to gain access to my own hardware is enough to prevent this from being a casual drive-by exploit.
:laugh:
A hardware bug must be resolved in hardware. As long as the user can run any software they want, other software can't protect against a hardware bug like this.You don't understand how SMT works either then. SMT is sharing a core's resources between multiple threads. The usefulness of SMT is decreasing with more efficient CPU architectures, while the complexity of all the extra safeguards throughout the pipeline to facilitate multiple threads is only growing. Back when SMT was introduced, it made a lot of sense since the pipelines were stalled much more and implementing SMT required very little die space. Right now SMT is mostly a marketing thing, with mounting security implications, and this die space would be better spent making faster cores.
Unfortunately though, I wouldn't expect SMT to go away anytime soon.Itanium had many flaws, probably the biggest one was a very complex instruction scheme.
But as of now, the primary bottleneck of CPUs is primarily cache misses, then secondary branching. If something is going to beat speculative execution for general workloads, it needs to solve/avoid these two problems.
If you want to bring down a country with a powerful military, this is the way to do it. As Sun Tzu said, to defeat the rider, kill his horse.