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.
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?
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