Google security researchers have come to the conclusion that speculative execution attacks are here to stay without drastic changes to modern CPU architectures, such as removing speculative execution entirely.
Spectre is here to stay: An analysis of side-channels and speculative execution
Related:
Patch for Intel Speculative Execution Vulnerability Could Reduce Performance by 5 to 35% [Update: 2]
Qualcomm Joins Others in Confirming its CPUs Suffer From Spectre, and Other Meltdown News
Congress Questions Chipmakers About Meltdown and Spectre
What Impact Has Meltdown/Spectre Had on YOUR Systems?
Intel Admits a Load of its CPUs Have Spectre V2 Flaw That Can't be Fixed
Intel FPU Speculation Vulnerability Confirmed
New Spectre Variant SpectreRSB Targets Return Stack Buffer
Intel Discloses a Speculative Execution Attack in Software Guard eXtensions (SGX)
Intel 'Gags' Linux Distros From Revealing Performance Hit From Spectre Patches
MIT Researchers Claim to Have a Solution for Some Speculative Execution Attacks
Spectre, Meltdown Researchers Unveil 7 More Speculative Execution Attacks
New Side-Channel Leak: Researchers Attack Operating System Page Caches
(Score: 2) by Arik on Saturday February 16 2019, @08:15PM (4 children)
Which RISC CPUs use speculative execution?
I don't remember either the Alpha or the PPC using it. Rather thought it was introduced specifically to make the superscalar x86 architecture work.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by RS3 on Saturday February 16 2019, @08:51PM (2 children)
Oh gosh, Arik, thanks for asking, but I'm not sure why this happens so much online: I never said RISC CPUs use speculative execution. I was only parroting what I read in many online articles about vulnerabilities, and they all say that RISC is also vulnerable.
That said, after a quick search on terms like "RISC" "ARM" "vulnerable" you can find many articles. Many will state that ARM is vulnerable to Spectre but not Meltdown. Many refer to ARM's "speculative execution". ARM is generally considered RISC. I'm not sure how to define RISC vs. CISC, and it may be that speculative execution is okay to be included in a pedantically defined RISC processor. Here's some good reading on the subject- especially the paragraphs containing "RISC" and the AMD 29000 : https://en.wikipedia.org/wiki/Superscalar_processor [wikipedia.org]
(Score: 2) by Arik on Saturday February 16 2019, @09:04PM (1 child)
If laughter is the best medicine, who are the best doctors?
(Score: 3, Interesting) by RS3 on Tuesday February 19 2019, @07:40AM
Sorry- verbal skills are my weakest suit. I try to be as clear as possible and people always find a way to misunderstand. Your question was absolutely okay- I was just trying to clarify what I wrote. I keep having a problem here (mostly here, and it just happened 2 more times) where people extrapolate from something I write, but then pin that extrapolation back on me, in a kind of accusatory way, and demand I defend something I never wrote, and is false and I disagree with. You weren't being accusatory at all; I'm just frustrated that I can't seem to write clearly the first time around.
What I meant to write was: there are many vulnerabilities, not just speculative execution, so a CPU which does not do speculative execution can still be vulnerable.
And repeating myself from earlier, it seems the problem is that the cache controller does not know memory protection boundaries, and if that's true, that's a horrible error. I'm still searching for a clarification on that possibility.
(Score: 2, Interesting) by Curlsman on Monday February 18 2019, @08:55PM
Alpha EV6 (21264) used out-of order execution:
https://people.cs.clemson.edu/~mark/464/21264.verification.pdf [clemson.edu]
"The Alpha 21264 microprocessor is a highly out-of-order, superscalar implementation of the Alpha architecture."
And https://en.wikipedia.org/wiki/DEC_Alpha [wikipedia.org]
And the OpenVMS OS designers believe they are resistant:
https://www.vmssoftware.com/updates.html [vmssoftware.com]
"VSI OpenVMS is NOT vulnerable to this issue, primarily due to its different, four-mode architecture. Specifically, VSI OpenVMS is protected against CVE-2018-8897 because it does two things differently than other operating systems:
1) OpenVMS doesn’t rely on the CS pushed in the interrupt stack frame to determine the previous mode. This means OpenVMS cannot be tricked into believing it was already in kernel mode when it was not, which is central to this vulnerability.
2) OpenVMS uses a different method to switch GSBASE; OpenVMS always performs the switch and makes sure the user-mode GSBASE is always updated to match the kernel-mode GSBASE."