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