Google Researchers Say Software Alone Can't Mitigate Spectre Chip Flaws (siliconrepublic.com) 98
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.
I for one am.... (Score:2)
Re: (Score:2, Funny)
... actually quite surprised.
Software engineers admitting something cannot be just fixed in software? Astounding.
Re: (Score:3)
I am. Though maybe it's just bad technology reporting. When they say "all processors that perform speculative execution will always remain susceptible" there's something wrong being reported. They should add in that this does not mean ALL processors (past, present, future, and from any vendor), and should end with "unless processors are redesigned."
Reading the summary as-is literally, it is disgreeing with itself.
Just always apply hardware access controls. (Score:4, Insightful)
Re: (Score:2)
The Spectre and Meltdown attack proof-of-concepts were for Intel processors, presumably also the clones, and the attacks are based on knowing internal specifics of their highly speculative execution engines. Ie, if you don't use a PC you're automatically a lot safe (though not completely), and if you're using a processor without a speculative execution engine then these attack vectors won't do anything at all. The chips that are vulnerable are very high end CPUs, not the stuff in your microwave or wifi rou
Re: (Score:3)
Re: (Score:2)
Is it even possible, though? That's like trying to make a turd sandwich taste good.
Maybe they should go back to the drawing board and find something better than speculative execution.
Re: (Score:2)
Re: (Score:2)
Because "Security". Joe at Best Buy knows that security always slows things down (driving, airport, etc).
Re: (Score:2)
Re:Just always apply hardware access controls. (Score:5, Interesting)
Re: (Score:1)
Technically it might be possible to fix but would require the state of all caches and buffers to be restored to the state before speculation started which would defeat the performance gain of speculation.
So yes, it's impossible.
The memory access is meltdown and has nothing to do with spectre.
Re:Just always apply hardware access controls. (Score:5, Informative)
It's hard to explain without getting EXTREMELY technical, but here's a SOMEWHAT technical explanation:
Back in "the old days" (6502, 68000, 8086, etc), a specific machine language instruction took a precise, deterministic amount of time to execute... 1 cycle, 2 cycles, 3 cycles, whatever. Always, and without exception.
Sometime around the AMD K5 (late 90s), we got to a point where the combination of cache and execution-time optimizations used by processors (speculative & out of order execution, cache, etc) made it SEEM like the days of deterministic execution timing were over. You could predict best-case and worst-case execution times for a given block of code, but ACTUAL runtime execution times had become seemingly random when you tried to measure them on an operating system like Windows or Linux.
It turns out, we were wrong. Execution times were as deterministic as ever... it's just that making sense of their timing had become too complex for humans to understand, so it SEEMED random. Then, "big data" and "machine learning" became common, and people discovered that execution timings weren't nearly as random as humans had come to believe they were.
Problem #2: due to the state various performance optimizations leave the CPU and its cache in, the amount of time it takes an attempt to do something prohibited to fail varies in subtle ways depending upon the values being protected.
So... taking advantage of analytics, machine learning, and lots of brute-force hammering & observation, it's possible for attackers to gradually discover the likely values of protected ram and registers. They can't necessarily do it with a single hit... but if they hammer away at something a million times and discover that a particular bit's value seems to be '0' ~70% of the time, and '1' the other 30% of the time... well, the bit's value is probably 0.
Here's another roughly analogous example: suppose you're attempting to discover the combination to a safe. Suppose the lock is designed to frustrate attempts to listen for pins falling into place by ensuring that EVERY dial position results in the lowering of one pin and the rising of another. HOWEVER... someone discovers that certain unsuccessful combinations produce a slightly different sound than others. Using deep learning techniques, the algorithm predicts that sound #1 indicates a combination that's almost right, while sound #2 indicates a combination that's completely wrong. By rapidly performing a few million experiments with different combinations, the algorithm is able to eliminate 99% of possible combinations, and focus on the 1% it believes are likely to work... and as it continues to experiment, it discovers a THIRD sound variant that appears to exist whenever the third number is equal to 17. By successively setting aside unlikely combinations, it eventually stumbles upon the correct combination to open the safe.
In security, this kind of problem is well known, and has a solution that generally works well: limit the rate at which an attacker can attempt different combinations. The problem is, that solution goes completely at odds against everything modern CPUs have attempted to accomplish for the past 50 years -- achieve better performance.
Ultimately, Intel and others are probably going to start making CPUs with a security gradient:
* The high-performance no-security portion that is designed to maximize performance, but makes no guarantees about security. Basically, "gamer" oriented CPUs will dedicate most of their silicon to this portion.
* High-performance with minimal security... designed to avoid blatantly leaking data to other processes, but still totally vulnerable to Spectre-type attacks. CPUs targeted to enterprise users will probably dedicate most of their silicon to THIS mode.
* The slow, separate, secure fortress. Totally separate, with no cache or optimizations at all, designed to guarantee absolutely deterministic execution times from the perspective of an outside observer. Basically, an 80386
Re: (Score:1)
Not all. Less powerful processors such as the ones in the Raspberry Pi devices, do not perform speculative accesses, and are thus not affected by Spectre.
Re: Just always apply hardware access controls. (Score:1)
The ARMv8 in the rPi most definitly do speculative execution
Re: (Score:2)
I wonder if this is can be mitigated in a hypervisor (Green Hills INTEGRITY, KVM, etc.) Maybe PC makers might be wise to have an onboard hypervisor as a way to limit damage.
Re: (Score:2)
Re: (Score:2)
True. However, it is about risk management. A hypervisor has a smaller attack surface than a general purpose OS. Yes, there are bugs in hypervisors, but generally a lot fewer.
Re: (Score:3)
As I recall, the problem is that speculative execution alters the state of the CPU and its cache, and there are ways to determine information about that state afterwards that don't involve violating memory access restrictions, like "hey, loading that address didn't take as long as expected, something must've pulled it into the cache already" - that sort of thing. So the question is how much can they make the state act like the speculative execution never happened without actually reaching the point that spe
Re: (Score:2)
Re: (Score:1)
Computers would be slow as dirt. Even branch prediction would have to be thrown out.
Re: (Score:2)
Re: (Score:2)
Do you want to go back to the computer you used in the early 90s? Because that's what you're going to get if you remove it entirely.As for the idea of not letting different apps share the same core- so you want to get rid of mutltasking? Because you have very few cores compared to the number of processes running. Sharing cores is basically how all multitasking works.
Re: (Score:2)
Do you want to go back to the computer you used in the early 90s? Because that's what you're going to get if you remove it entirely
I'm not really sure that the computer I used in the early 90s had thousands of cores enabled by sub-20nm lithography.
Re: Just always apply hardware access controls. (Score:2)
A 3 GHz Apple IIgs would still be pretty useful. Extend it to 64 bits and add a graphics coprocessor. If these attacks do turn out to be serious issues we might have to take a step back from the current levels of complexity.
Re: (Score:3)
You have assumed a multicore CPU that does not share the last level cache between cores, which is not necessarily true.
While I have not a description of a Spectre exploit that specifically involves a multilevel cache, and I have not seen that case specifically rejected either.
Re: (Score:2)
The issue is that you don't *know* whether the memory being fetched is accessible until the data comes back from DRAM. So you can assume all accesses to DRAM are not accessible -- very very poor for performance -- and play it safe. Or assume it's accessible until it comes back from DRAM.
Of course, during that time you've also launched a whole lot of other memory requests that is speculative. And it doesn't matter that you end up discarding the results from the software interface perspective -- the cache (or
Re: Just always apply hardware access controls. (Score:2)
Re: (Score:2)
"bad cache invalidation"
Except the "valid" state of a cache line has an actual definition, and the cache line in question actually is valid. No one had ever defined a "Forget we were ever here" request.
You might think you could just add a method to mark every line you touched during a mispredict as invalid, but now you are open to timing attacks based on cache misses on which lines got evicted in the first place.
Re: (Score:2)
The side channel attacks do things like measure how long a set of operations take to execute, which gives extra information about what the operations actually did. That can tell you if some relevant data was already in the cache or whether it had to be loaded from RAM. Do the appropriate magic and you can start to deduce things about the contents of memory that you can't see.
That is, it's a side-channel attack. They're still treating the processor a a black box that you can't peek inside of, but you can sti
Re: (Score:2)
Not really. First of all, Spectre is not about the hardware letting you access memory it thinks you don't have permission to access, so memory access controls aren't relevant here. That variant did exist and has another name: Meltdown. Meltdown was a disaster. An Intel hardware bug meant an unprivileged program you could use the Spectre method to read all of kernel memory, even th
Sounds false, overconfident, and trendy & chil (Score:2)
Re: (Score:2)
I just think there may be more going on here than just "old stuff sucks"
Arrogance.
gimme that old 6502 (Score:2)
maybe make it run at a few 100 MHz, or upgrade to the 65816 architecture.... I think I'd rather have that.
Re: (Score:2)
Isn't the 68000 series immune to all this bullshit? The 68040 is better than the 65816, isn't it?
Re: (Score:2)
Re: (Score:2)
Several IIgs technologies had re-emerged after the IIgs faded, the first being the 65816 CPU used in later consoles, and the other was the Ensoniq DOC2 audio chipset which eventually found itself in the Gravis UltraSound (GUS) as the GF1 (actually based on the DOC3 chipset)
But honestly, 16-bit... is a non-starter, and in fact 32-bit is also a non-starter.
I would gladly trad
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Work did start on the 65832, but with Apples disinterest, stopped.
It's not a problem if you don't run unsigned code (Score:2, Insightful)
Re: (Score:3)
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.
Re: (Score:3)
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?
Re: (Score:2)
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.
Re:Oooh breaking news (Score:4, Informative)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Software can Mitigate, it may not be able to cure. (Score:2)
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.
Re: (Score:1)
Re: (Score:2)
Never stated it was the solution. Just mitigation.
Comment removed (Score:5, Interesting)
Re: (Score:3)
In the server and cloud world there might be a legitimate risk at some point, once we actually see an exploit in the wi
Industry bumbled, Intel is just the biggest. (Score:1)
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
Re: (Score:1)
If they deliver, I will probably switch back to AMD. Intel burned a lot of goodwill in the past few years.
Just keep in mind that *any* CPU design that uses speculative execution is fundamentally and unavoidably vulnerable to such attacks.
That includes AMD as well as Intel.
So if you're switching due to disliking Intel as a company more than AMD as a company, that's all good and well.
If you're switching under the assumption only Intel CPUs do speculative execution and are vulnerable, you won't be solving any problems.
The unfortunate fact of the matter is raw instruction execution speed in CPUs isn't increasing le
Re: (Score:2)
Speculative execution is pretty flawed, with new ones found seemingly every day.
But getting rid of it entirely would set us back to the Pentium 1 and 2 days, where a 400mhz chip was priced out of most peoples reach and was the peak of performance, where most of our $1k usd processors ran 100mhz.
That's a HUGE cost. One not everyone would even be willing to pay.
But if you are wanting to build a new PC without speculative execution vulnerabilities in it, go fish a 486 or sparc out of the trash and go to town. Waiting may only give you less options as such hardware becomes more rare.
The first generation Atom had no speculative execution and while it did dispatch executions at about the same speed as a Pentium, it ran much faster, had simd instructions and was cheap.
Re: (Score:3)
Let me start by defending Intel before turning this around. Speculative execution attacks are extremely difficult to execute in any constructive way without detailed targeted knowledge and access to the machine. As yet there's no known case of it actually being used and with very good reason: Pretty much every other security exploit is easier and more effective to execute with the exception being attacking a VM from another VM. Spectre / Meltdown really shouldn't come into consideration when buying a CPU un
Re:Bad time for Intel CPUs (Score:4, Insightful)
I'm assuming at this point we're probably at least a couple of CPU generations away from Intel fixing this properly.
unfortunately, it's much wose than the press is making out. i've had to investigate this in-depth as part of the design of the libre-riscv soc, because we criically rely on out-of-order execution for the vectorisation. i was shocked to learn that even in-order systems are potentially vulnerable to timing attacks.
the first thing that people need to get absolutely clear: spectre was *just the first* in a *class* of timing attacks that opened researchers and hardware designers eyes to a blind-spot in computing architectures.
the definition of a timing attack is as follows: one instruction may affect the completion time of past OR future instructions through resource starvation / contention, OR through state not being reset after use to a known uniform initial state.
the FIRST spectre attacks were against memory and caches, on speculative designs.
however it is perfectly possible, for example, for a multi-issue IN-ORDER system to have insufficient numbers of register ports, such that a certain unique combination of instructions may be arranged by an attacker to starve future instructions of the ability to complete instructions in a uniform time... and REQUIRE that they stall.
by forcing instructions to stall, that is the very DEFINITION of a timing attack.
against an *IN-ORDER* design.
now, it is possible to put in place certain speculation mitigation barriers in hardware, however these barriers *ONLY* occur at interrupts, exceptions and, at a software / OS level, on "context switches". hence the reason why this paper says that no matter what hardware designers try to do, *intra-process* attacks simply CANNOT be mitigated without moving to an *INTER*-process software security model.
FastCGI is toast, basically.
there is a solution, and it's going to require a massive world-wide campaign to introduce a concept to the entire computing software world: the creation of intra-process speculation barriers. if we wish to keep using FastCGI, and if we wish to keep using Firefox and python-gevent (the single-process paradigm), we *need* a hardware instruction that "quiesces" internal state *AS IF* the hardware had just made a context-switch, terminating all speculative execution, resetting all internal state and so on.
one way in which that may be possible to do in an out-of-order system that does not have such hardware-assisted in-process speculation barrier instructions is to issue about a hundred NOPs. the back-lash against doing so will be extreme, however it's not like there's much of a choice, here.
bottom line is: this has been a major, major oversight by the entire computing industry for over 25 years. it's a problem *across the entire industry*, not just Intel, not just AMD, it's *everybody*. it's not going to be fixed in a couple of hardware revisions by one company.
Google just wants UNIX out of their cloud (Score:1)
Not entirely true but mostly true. (Score:2)
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
Re: (Score:2)
The shills Intel pay at AMD?
https://www.amd.com/en/corpora... [amd.com]
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.
Re: (Score:2)
So, one computer per user then (Score:2)
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".
No, it's one per security principal (Score:2)
The irony (Score:4, Interesting)
Re: (Score:2)
The Cloud has rained (Score:2)
Best for security if everyone backs off from multi-tenant cloud servers for now. It was a nice try, but too insecure.
Internet of Things will have issues like this (Score:1)
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.