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.
Until I get a cheque for the hundreds of Intel chips I paid for with wide open backdoors for the NSA and nowhere near the promised speed - INTEL OWES ME MONEY.
PAY UP YOU FUCKERS!
Well Duh, its a CPU hardware flaw, can't redesign a CPU with firmware or a OS fix. You can mitigate a threat of which I know of no threat around as yet. Eventually I figure CPU's will overcome this by not requiring it because they will add more cores, and make speculative execution something that won't be needed.
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
Why? Why do you need to run code on my machine? Why should I be required to trust you to run code when it's not necessary?
The web worked just fine - better, in fact - before JavaScript infected browsers. You didn't have to worry about "drive-by malware" in the old days of the web, because it just wasn't possible.
Why should I allow unsigned, unreviewed, unverified, and ultimately untrusted code on my browser? Because Rockoon says so?
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.
This is an INTEL flaw, introduced when Intel was way behind AMD (AMD had just invented true dual core and AMD64, now x64 used by all current x86 chips from both Intel and AMD). Intel had Netburst, a very long pipeline architecture shilled by outltes like Slashdot at the time (the race to 10GHz).
Intel hd to go back to the architecture of the Pentium 3, which it merged with AMD's (then) latest tech (legal via cross patent agreements). But Intel deliberately missed out thread memory access protection- the LOCK and KEY hardware that gives each thread a unique id used to 'unlock' access to memory belonging to that thread- hence SPECTRE and other problems today.
By refusing to implement thread security, Intel chips used less power, could clock faster, and have lower memory latency- ALL advantages that meant Intel CPUs ruled over AMD ones till AMD Ryzen.
AMD always implemented hardware 'lock and key' thread security.
Today Slashdot shills the idea of a 'universal' CPU problem that in reality only applies to Intel (AMD's Ryzen parts have no proven practical vulnerabilities that can actually work in the real world). Intel pays generously for this shilling.
AMD's coming Zen2 (not to be confused with the already released Ryzen 2) later this year finishes off Intel for good- but Intel still sits on a mountain of cash which will be used to pay for more fake news articles of this form.
Spoken like a truly computer illiterate.
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?
He's right, even if you don't like it.
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.
Why? Why do you need to run code on my machine?
Because otherwise my website's adverts won't render right on your computer.
Why should I be required to trust you to run code when it's not necessary?
Go on, turn off javascript in your browser. I agree that it ought not be necessary, but in current practice, it is.
The web worked just fine - better, in fact - before JavaScript infected browsers.
Marginally better. Browsers were very shitty before javascript, but it certainly hasn't made them less shitty.
You didn't have to worry about "drive-by malware" in the old days of the web, because it just wasn't possible.
That's not automatically true. It's not exactly difficult to cause an entity bomb and hey maybe your browser happens to have a buffer overflow that can be triggered that way. I would guess that if you went and looked for them, you can find plenty of exploitable holes in old browsers. And there's the exploits in various libraries browsers tend to use, like those used to decode pictures in various formats. Some of those have had vulnerabilities in them too.
Why should I allow unsigned, unreviewed, unverified, and ultimately untrusted code on my browser? Because Rockoon says so?
Signing is no guarantee of review, verification, or trust. All it does is give the keys to your kingd^Wcomputer away to some third party and provide a nice goose with golden eggs to the rootCA operators.
Review is no guarantee either, see "underhanded C contest". Verification means what, exactly? Someone held up a photo to a phone running a "verification app" that caused some shmuck faraway to take a look, squint a little, and push an "approved" button? Does this "trust" thing hold up to anything in your world?
So I agree that javascript in the browser is a bad idea, as are many similar ideas like java or flash in the browser or VBA in redmond office documents, autostart files on external media, and so on, and so forth.
I violently disagree that code signing will solve anything here. The correct fix is to simply stop executing code from untrusted sources, and "random website" or "incoming file" are both untrusted sources. So turn off that javascript in your browser and complain to each and every webmaster that their shitty website doesn't work properly or at all in javascript-free browsers. Then get all of your friends to do the same. But for $DEITY's sake, forget about that signing boondoggle.
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?
so any site that presents a valid SSL cert can't/won't hack your machine... yeah
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
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 still in this mindset. I remember a time when one of the first common sense security practices was to disable JS in your browser if JS was supported.
Now, so much is passed to the client to save server side processing/execution time, you can't even render basic views of a page without piles of JS and the vast majority of it is completely unneeded, at least for the consumer.
While there is a certain admirable degree of convenience of running more sophisticated applications right in a browser, it's always been a security risk no matter how clever and sophisticated JS engines tried to isolate and sandbox the untrusted code. Certain modern expectations of UIs handled by JS could be extracted into CSS/HTML standards that are implemented by browsers (trusted code) without too much sacrifice.
The reason this is the case is because people accepted it. In most cases, people accepted it out of pure ignorance of the technical details behind the scene. If the vast majority of people around understood the technical details, trade offs, and then refused to run random embedded JS, you'd find the web looks quite different than it does now by simply disabling JS.
While a situation or state of affairs may be the current circumstantial case, that situation or state of affairs is not guaranteed to remain unchanged. I feel like most the people in arms protecting JS are heavily invested in JS development. I rarely need or use JS (in a sense that I can be happy with pure HTML5/CSS3 pages, obviously I use JS constantly if you go to any modern website). However, just about everything I expect from a website can be handled entirely without JS (but instead, its littered with it).