Link to project zero blog; includes vendors’ comments/responses. (No statement from Intel to Google yet.)
Quantum computing is going to have even worse vulnerabilities, like someone taking over a computer by waggling an entangled electron on the other side of the planet. And the worst of it is that whether or not the vulnerability actually exists is going to be probabilitistic.
Thinking about it, the brain is like a quantum computer (except not really*). It comes to answers that are approximately correct very quickly. It seems able to explore multiple outcomes almost simultaneously. It is easily perturbed. Nobody really knows how it works. It is expensive and delicate.
Whether we end up going the Dune/Herbert route or the Wolfbane/Pohl & Kornbluth route is left as an indeterminate outcome for the reader.
*before some smartass says “that’s a very poor analogy”
1 Like
Of course, those who cry that “there is nothing we can do about it” generally devote less that 1% of their time towards actually trying to do anything about it. My response is generally an empathetic “What have you tried so far?”
1 Like
As I understand it from a skim of the Spectre paper, the mechanism for extracting the desired sensitive information from the target program is not by reading the contents of the cache, but through a timing attack: If you want to know the value of the byte at address x, then you cause the program to speculatively attempt to access address y + *x, causing that address to end up in the cache. Then, you cause it to read values from y + 0 to y + 255, and infer from timing whether the read was a cache hit or miss.
It depends on finding a program which does certain types of accesses based on values you control (but evidently plenty of programs do), and a fine-grained timer to have a shot at differentiating cache hits from misses. The proposed mitigations I’ve seen include reducing precision of the timer available to javascript, and modifying compilers to detect programs which have the necessary characteristics to be exploited and automatically inserting guards.
3 Likes
Very useful explanations from yourself, @eraserbones and others and the one word i’m glad to see repeated here is ‘javascript’. There’s the nuclear option with noscript/umatrix i suppose but i like to think a lot of these attacks could be mitigated somewhat by the browser updates which are forthcoming.
ETA: Not that that’s really dealing with the fundamental issue but it’s reducing the attack surface.
Intel announced a fix. I am curious about before/after benchmarks…
Are you suggesting that a spectre is haunting Europe computing?
4 Likes
Phoronix have done some benchmarking on the Linux patches, using a Haswell processor (released 2013-4).
https://www.phoronix.com/scan.php?page=article&item=linux-kpti-pcid&num=1
It looks like for the average users day to day use on recent PCs, including gaming, the performance hit will be minor at worst. I have absolutely no reason to believe that any MS or Apple OS patches will be different.
Now all I need is a benchmark for Penryn processors from 2008.
1 Like
Most people usually mean “there is nothing useful we can do about it” when they say that.
Yes, they could not patch their computers, or amputate their legs in response to these vulnerabilities, but neither choice will help.
2 Likes
It seems we may have gone from “OMG we’re all gonna havta burn our computers and live in the woods on nuts and berries” to “there’s a fix” in a day…
May be worth waiting a few more days before you reach for the gasoline.
4 Likes
Well, three days, when Google were probably hoping to use the next week to properly test Retpoline.
But I get your point.
News about the vulnerabilities leaked early. Companies have known about the two vulnerabilities since June & July of 2017. Had news been disclosed properly, news of this fix likely would have been included.
So maybe when vulnerabilities are leaked early, beyond making sure all software and OSes are patched up, perhaps we should wait a bit longer to see what else the companies involved might have prepared.
I’ll take this at face value for now. My only Internet-facing Pi doesn’t run any wild code.
2 Likes
Thats what I thought. If the exploit is to see behind the curtain to predictive processing, then just close the curtain. Don’t change the processing to be invisible. Just block the door. I figured it would be minimal.
People have been working up to it since earlier than that:
There is mention in the above paper that some nonstandard system clock techniques defeat the exploit, which might be of some use to end-users.
1 Like
A list of which ARM cores are affected, and remedies:
1 Like
This topic was automatically closed after 5 days. New replies are no longer allowed.
