SoylentNews is people
SoylentNews
posted by
martyb
on Saturday February 16 2019, @02:08PM
from the so-that-means...-we-are-screwed dept.
from the so-that-means...-we-are-screwed dept.
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
This discussion has been archived.
No new comments can be posted.
Spectre is Here to Stay: An Analysis of Side-Channels and Speculative Execution
|
Log In/Create an Account
| Top
| 36 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
sillema sillema nika su
(Score: 3, Insightful) by Arik on Saturday February 16 2019, @03:12PM (11 children)
As I recall in the late 90s the fastest processors were more simplified, things like the DEC Alpha took a more direct path to speed and it did work. The market didn't reject them because they weren't fast. It was more about the industry addiction to blob compatibility.
Someone more involved in modern RISC might chime in here.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Saturday February 16 2019, @03:56PM
I would assume that Alpha would have been exploitable in this manner.
But as you point out, it was simpler, so perhaps easier to fix?
(Score: 3, Insightful) by RS3 on Saturday February 16 2019, @05:02PM (5 children)
Absolutely agree.
> It was more about the industry addiction to blob compatibility.
My angle: driven by short-term mass profit.
RISC CPUs are also vulnerable, although slightly less so. We're currently seeing a rise in RISC, much of it ARM and ARM-Cortex processors- Chromebook, phones, more RISC-based laptops being announced. I think if RISC, like Alpha, had taken off 20 years ago I suspect we'd be no better off, because the vulnerabilities affect RISC too, and profit-driven CPU development would have ignored the pitfalls.
To me it's the same old story. I often cite the space shuttle Challenger disaster where the engineers pleaded to cancel the launch, but greedy managers overruled them. Not sure how that political structure evolved where the people who truly _know_ what's going on do not have final decision power. I suspect many engineers knew about the Spectre and Meltdown problems but were hushed. I'd love to see the results of a future investigation. My cynical side perceives that the general public is becoming sick of and numb to all of the vulnerabilities, data leaks, etc., and it's not "viral" anymore and they just want to hear about the next hot topic.
Still trying to understand the details. Articles are too long, too deep, or too vague. My hunch at this point is that the cache controllers do not honor the CPU's memory protection boundaries. If that's the case, I doubt that even CPU microcode can fix it, but a future hardware design is needed that incorporates the cache controller fully into the memory control system.
(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."
(Score: 1, Informative) by Anonymous Coward on Saturday February 16 2019, @08:38PM (3 children)
Alpha had simple branch prediction. They wanted to go all in [ualberta.ca] with it for the EV8.
(Score: 2) by Arik on Saturday February 16 2019, @08:44PM (2 children)
Well the Amiga proved you don't actually need a fast CPU if you design everything else around it I suppose.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by RS3 on Saturday February 16 2019, @08:58PM (1 child)
That's a great point. I never had my hands on an Amiga but always admired them. I think they made better use of sort of distributed processing with more intelligent peripherals, but I may be wrong. Probably much cleaner tighter code too. I've always been surprised (annoyed) by how much work most CPUs do that could be done by auxiliary processors. I can't remember specifics, but I clearly remember machines where the main (and only) CPU did RAM refresh, CRT character scanning, etc.
(Score: 2) by Arik on Saturday February 16 2019, @10:09PM
It had dedicated chipsets to offload much of the work onto, and tight code? Haven't examined the code though IIRC it was leaked a few years ago, but that was definitely my impression. This was the end of the classic microcomputer days, OS code wasn't something written in a high level language then trusted to the compiler, it was typically hand massaged by people that read 8-bit. Even application code normally got that treatment, after some profiling to see which loops got executed most often (we're all lazy and we'd often not get around to optimizing the bits that didn't get called often. Unless we were running out of storage space.)
It had sound and video systems that pretty much did their job all on their lonesomes - the cpu pointed them in the right direction and they took it from there. The CPU doesn't need to be all that fast in that position - it just needs to do what a CPU traditionally does, what a Z80 did well enough and fast enough for most things. It executes the main logic of the program and runs the shows behind the scenes. You want a video? Point the vidcard at the file and tell it to go. Want to read a bunch of data from the HDD? Tell the controller what you need and where you want it put, check back every few cycles to see if it's done yet.
If laughter is the best medicine, who are the best doctors?