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.

Comments

Just always apply hardware access controls.

[KirbyCombat]

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?

Re:Just always apply hardware access controls.

[msauve]

But the summary claims "...all processors that perform speculative execution will always remain susceptible...". That's a blanket statement which covers all processors, existing or future.

Re:Just always apply hardware access controls.

[Miamicanes]

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

Bad time for Intel CPUs

[bangular]

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.