Slashdot Mirror
Google Researchers Say Software Alone Can't Mitigate Spectre Chip Flaws (siliconrepublic.com)
A group of researchers say that it will be difficult to avoid Spectre bugs in the future unless CPUs are dramatically overhauled. From a report: Google researchers say that software alone is not enough to prevent the exploitation of the Spectre flaws present in a variety of CPUs. The team of researchers -- including Ross McIlroy, Jaroslav Sevcik, Tobias Tebbi, Ben L Titzer and Toon Verwaest -- work on Chrome's V8 JavaScript engine. The researchers presented their findings in a paper distributed through ArXiv and came to the conclusion that all processors that perform speculative execution will always remain susceptible to various side-channel attacks, despite mitigations that may be discovered in future.
....not surprised.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Is my understanding not correct? I thought that these vulnerabilities were due to processors not applying memory access controls during speculative execution. For me personally, I was very surprised to find out that memory access controls could be bypassed at all. Isn't it just a matter of always applying memory access controls? Isn't that why the access control is in the hardware?
Some people are always trying to poo-poo old technology. I suspect this is a play to act like every CPU made before yesterday is no good. "Sorry folks, you're going to have to turn on all those old computers we can't control^H^H^H Uh, I mean, those vulnerable systems for your own safety." That or so some smug security weenie can sit and smirk pointing to some ridiculous "researcher" saying "it's impossible to prevent". I just think there may be more going on here than just "old stuff sucks"
maybe make it run at a few 100 MHz, or upgrade to the 65816 architecture.... I think I'd rather have that.
I just think there may be more going on here than just "old stuff sucks"
Arrogance.
We need to get away from this unsigned, unreviewed, wild code (like javascript) running on your machines. Lock it down and stuff like this won't be a problem.
-- these are only opinions and they might not be mine.
Having handrails will help mitigate people from dying from falling down the stares. It doesn't stop it, or even prevent it. It is just a tool to help regain balance after you have lost your step.
Software can Mitigate the problem, by catching the most common and easiest calls to cause the issue.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
We need to get away from this unsigned, unreviewed, wild code (like javascript) running on your machines.
Lock it down and stuff like this won't be a problem.
Systems for whitelisting apps and websites can help. But then the problem just shifts to how much do you trust whichever app stores or website whitelists you are using which are basically the same thing as a signing system. I mean I try to be careful about which apps I download, but if you want your computer to be a general purpose computer then you have to have some flexibility to run unsigned code. As a developer that often means my own code. Otherwise it is an appliance.
We need to get away from this unsigned, unreviewed, wild code
As a representative of programmers everywhere, can you kindly take your idea and go fuck yourself?
"His name was James Damore."
I'll be the first to admit this isn't my area of expertise. But after following these developments peripherally, I've been holding off buying a new desktop for awhile.
It seems like Intel has bumbled this at every step. They've put out a lot of misinformation causing a lot consumer confusion. It seems like every time they exclaim "it's fixed!" researchers say that's not the case. I'm assuming at this point we're probably at least a couple of CPU generations away from Intel fixing this properly.
On top of that, they've also been fighting the 10nm battle. More empty promises and missed deadlines on that front as well.
When I compare my current aging Intel system to single thread performance of the latest generation, it just doesn't justify the cost. AMD claims Zen 2 will fix all their problems. If they deliver, I will probably switch back to AMD. Intel burned a lot of goodwill in the past few years.
They want GOOGLE Cloud not FreeBSD cloud or Linus' Cloud Spectre can be mitigated by implementing a move operation that moves central data to a cloud then fails, then recovers using self repairing techniques, then defaults back to a node. I dont know much about hacking though
If you are executing someone else's code natively on the CPU then it's true that it cannot be fully secured. However, if you execute (JavaScript) code through an interpreter engine rather than using JIT/dynamic recompilation engine then it is by default that spectre cannot be accessed. However, this would be throwing years of effort away in making JavaScript fast so that advertisers can exploit you easier without you noticing the slower execution speed. For this reason, the safest and simplest JavaScript engine is out of our reach which in turn has lead to the internet becoming a horrible mess of evil JavaScript, exploiting us at every turn.
TL;DR: STOP REQUIRING JIT, YOU ASSHOLES BECAUSE IT'S FUCKING UP EVERYTHING.
Anons need not reply. Questions end with a question mark.
If the examples of the successive failed patches are anything to judge, software it not the solution. But any person with half a brain knows that from day one.
or more precisely, per security principal.
I for one welcome our new architectural overlords, that is, whoever can make an efficient multi-core, multi-cache,.... multi-everything architecture, perhaps that only shares over high-level interfaces over fibre connections, or whatever.
And I guess those high-level physical interfaces will have to include timing randomization "chaff".
Where are we going and why are we in a handbasket?
Inifinite cores wouldn't make speculative execution not needed. Speculative execution exists because you're trying to do things sequentially. Putting another core in there won't speed it up in any fashion- to avoid speculation you have to wait until the branch is determined. You could remove speculative execution and the optimization it provides, but yo'll end up with a FAR slower processor as your core will be idle from the beginning of a branch statement until its done- putting in a lot of noops into the pipeline. The deeper the pipeline in the architecture, the worse it will be.
I still have more fans than freaks. WTF is wrong with you people?
The shills Intel pay at AMD?
https://www.amd.com/en/corpora...
They admit there are hardware issues and that page describes which software mitigations are required.
ARM have also admitted all of their speculative execution cores are vulnerable to some of the spectre attacks.
And the much-maligned, all-but-dead Itanium is immune to Spectre. Fancy that.
Best for security if everyone backs off from multi-tenant cloud servers for now. It was a nice try, but too insecure.
The fundamental flaw dates all the way back to the Power 1 processor/architecture from the early 1990s. Intel didn't come to the party until 1996 (the chip was in development sometime before that, likely after 1991 or 1992 when the Pentium engineering samples would've first been released.) Even in that case the problem doesn't reveal itself until you have single package cache-coherent processors, which limits practical application of these flaws to Hyperthreaded pentium 4s, Core series processors, and later. Still a major issue, but between the power guzzling of the P4s and the Intel ME of the late Core2 and later chips, it isn't that common of an issue. Furthermore any dual-package chips, like the Core2Quads can have this problem fully mitigated by only running kernel code on one pair of cores, and only running user mode code on the other physical die with pauses in place for the companion core during sensitive function calls. Alternatively at an original Celeron-like level of performance reduction, you can disable l2/l3 cache and only run with the L1, which will make cache hits much less likely and much harder to trigger. Combine these with powersaving reclocking and kernel mode process statistics and it should be easy to notice a rogue process trying to sidechannel attack and either shut it down, or reduce its process priority enough to make its chances of coherent data recovery minimal.
Having said this, I still think it is a huge bug. I think with REAL access to Intel ME by developers/end users a lot of it could be mitigated (since you could push sensitive crypto operations to the ME core at the expense of speed, and properly isolate that data from the cache.)
Really though, this is just a call for fully open source audited and user controlled crypto processors outside of the general purpose cpu. These attacks are primarily useful for recovering authentication materials, which are short and retained in memory in a clear format. While other sensitive data COULD be leaked, practically speaking most of it won't be retained in memory in a cache coherent form long enough for it to matter.
As far as AMD and Ryzen goes: the same speculative execution issue applies. It *MIGHT* not apply to Power 8/9 if they really do support disabling speculative execution as one of the boot time processor straps, however Intel has never provided that feature, nor has AMD. Personally Intel ME, ARM TrustZone, and AMD's Secure Processor (Another TrustZone secure enclave implementation, along with Intel ME style motherboard or system management features) is a far bigger security concern to me. I have no way of auditing the code or mitigating the risk. With Spectre flaws, as long as you verify code running on your system or limit timing information such that the code can't get accurate timing statistics back, the problem is limited in scope. However with the proprietary management engines we are barred from looking at the inner works and from Right to Repair style replacement of the code when it is shown to be faulty and the manufacturer refuses to provide a replacement, some of which may be implementation (motherboard or cpu) specific and thus beyond the scope of their reference implementations.
Until all our processors go back to being cryptographically unsigned, our bios chips go back to being read-only without the manual choice of enabling a bios write jumper (this was broken back at the beginning of the move to SPI bios chips, which now default to writeable unless both the software running on the system tells it to go into read only mode, as well as the strap pin on the SPI chip package... which can be voltage glitched from within many systems to reset it and allow writing, requiring either the SPI chips themselves to be fixed, or the chip interfacing to them to perform write protection itself, which is what intel did with its later chipsets, leading to the Ibex Peak and later processors having unwriteable memory ranges that could only be updated with signed bios updates that were uploaded either during system initialization or copied from the OS into an unprotected memory range and then verified and installed to the protected ranges during next boot.
This is the sort of thing that scares me about IoT. What happens when the processor in my desk lamp has an unpatchable hardware bug? I doubt that I'll be able to replace just the processor.
Of course, PATCHING an IoT object has it's own issues. How do I control who (and when) does the patching.
because presumably, a security principal trusts itself not to spy on itself.
Where are we going and why are we in a handbasket?
Okay, use Firefox with NoScript. That prevents all scripts from running, unless you allow them by domain.
Go ahead and use the web without enabling anything. Find anything you can use? Anything?
If you don't want to allow unsigned, unreviewed, unverified, and untrusted code in your browser, you can. No problem.
Now try to do anything on the web.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
But we needed that CPU power for 4K and 6K and 8K games.
Domestic spying is now "Benign Information Gathering"
Running every process on its own core, with its own cache might help. Could even have each process with a few cores sharing cache for multiple threads.
https://en.wikipedia.org/wiki/Inverted_totalitarianism
No, it absolutely wouldn't. Because you'd still have to wait for the result of every possibly branching instruction in order to execute the next. Having a billion cores per app won't fix that.
I still have more fans than freaks. WTF is wrong with you people?
Never stated it was the solution. Just mitigation.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I'm probably getting my vulnerabilities mixed up but my understanding is one process spying on anthers cache misses and hits so sandboxing would help.
https://en.wikipedia.org/wiki/Inverted_totalitarianism