Microsoft and Google are jointly disclosing a new CPU security vulnerability that’s similar to the Meltdown and Spectre flaws that were revealed earlier this year. Labelled Speculative Store Bypass (variant 4), the latest vulnerability is a similar exploit to Spectre and exploits speculative execution “that modern CPUs use. Browsers like Safari, Edge, and Chrome were all patched for Meltdown earlier this year, and Intel says these mitigations are also applicable to variant 4 and available for consumers to use today.”
However, unlike Meltdown (and more similar to Spectre) this new vulnerability will also include firmware updates for CPUs that could affect performance. Intel has already delivered microcode updates for Speculative Store Bypass in beta form to OEMs, and the company expects them to be more broadly available in the coming weeks. The firmware updates will set the Speculative Store Bypass protection to off-by-default, ensuring that most people won’t see negative performance impacts.
This cat ain’t going back in no bag anytime soon.
Speculative execution is taking a beating. I knew from the start that spectre wouldn’t be the end of it. By the time we’re done we might just conclude that speculative execution is too insecure for hardened systems.
It’s not all bad news though, if we nix these long speculative pipelines in superscaller CPUs, suddenly that frees up tons of space on the CPU die to do bigger and better things with. Single threaded performance will regress, but we could make progress in other areas like VLIW. Given how prevalent vector algorithms have become, I would welcome such a development.
http://www.isi.edu/~youngcho/cse560m/vliw.pdf
So… Itanium or Crusoe were good ideas after all? O_o
Let my fire up my trusty old rx8640
Itanium failed thanks to AMD, if the idea of AMD64 never came to be, we would have to endure Itanium no matter what.
Maybe. But I suspect we’d still be using 32-bit x86 if AMD64 didn’t happen, just with PAE to go above 4 GiB of RAM…
Update me on this, but isn’t the problem still basically not honouring the security boundaries while speculatively executing? They just have to make it an absolute cutoff when trying to speculate across security boundaries.
There’s still plenty of performance available for speculative execution within the same process/privilege.
I actually don’t know what benefits there are speculating across processes/privileges in the first place, since I wouldn’t imagine you’d do any heavy workloads with tons of system calls and the like.
kwan_e,
The issue is that even if the speculation does not cross a protection boundary, it can still leave behind measurable side effects (such as the TLD cache modifications or cpu clock counters). Spectre exploits such side channels to leak data from outside the address space.
Ultimately, I’d argue that reserving some cache for speculative execution is necessary – basically, enough extra cache to unwind all speculative actions.
(So, a speculative action could bring cache lines in, but they’d be flagged as speculative and old cache lines not evicted, until the speculative action is committed, at which point the old cache lines would be evicted and the flag cleared. If the speculative action is cancelled, the new cache lines would instead be evicted.)
bhtooefr,
Cache line eviction is itself a side effect. Therefor speculative execution must not be able to evict (or populate) the regular cache until the speculative branch is confirmed. This would require two separate caches. But this opens up a can of worms because a computer could have L1-L3 caches, is it ok for the side effects to remain in any of those or are all side effects banned because they could leak information from the speculative branches?
If we have normal L1-L3 caches plus speculative L1-L3 caches, the new cache coherency would add complexity and expense, but at least that would isolate the speculative execution side effects in the caching subsystem.
…but wait, the speculative execution on another core may technically be under an attackers control (cpu speculation happens in both kernel and usermodes). So if there are any side effects in the speculative L3 cache, there’s a theoretical possibility for the attacker to measure it by setting up controlled speculation execution in advance on another processor.
We really have to question every single assumption because when we do a lot of theoretical vulnerabilities crop up. Well funded agencies and unemployed hackers living at home with too much time on their hands could turn those into actual exploits.
In addition to cache based leaks, we may find that the clock cycles can change depending on speculative branching, how are we supposed to mask that? It’s easy to increase the time taken so that speculation has zero clock based side effects, but that nullifies the performance motivations of speculative execution in the first place.
And while those can often be mitigated with changes to software and hardware, it will very likely involve disabling speculative execution at vulnerable code locations.
I think that intel is dragging it’s feet in admitting the scope of the problem, but I’m predicting that ultimately we will get new CPU flags that will enable/disable speculation for specific instructions or entire processes (similar to cli/sti). There will be an uproar about how users and developers shouldn’t have to concern themselves with architectural security flaws, but out of pragmatism linux and other operating systems will incorporate this flag and allow administrators to enable/disable speculation for individual processes.
I hope this accelerates us toward things like The Mill (https://millcomputing.com/)
Hi,
Yes – if you’re like hearing about discoveries of new security problems, then it’d be a lot of fun to switch to an entirely untested architecture where all of the problems are currently undiscovered.
– Brendan
I never mentioned switching to anything, but not investigating better alternatives to a broken architecture because anything new might have unknowns, well that’s stupid.
See http://www.osnews.com/story/30384/C_is_not_a_low-level_language (and associated article) for more enlightenment.
Edited 2018-05-22 13:59 UTC
Hi,
Stupid is not understanding the difference between an architecture (e.g. 8×086), an implementation of an architecture (e.g. “Core 2 Duo”), and design practices (that could be used in the design of any implementation of any architecture).
Spectre is a flaw in design practices (specifically, a flaw in speculative execution). It has nothing to do with any architecture. That’s why it effects multiple different implementations of different architectures (e.g. 80×86 and ARM) that all happen to use speculative execution.
The alternative to speculative execution is to have a CPU that sucks (because nothing hides the cost of branches causing the performance of single-threaded code to be ruined, which in turn ruins the performance of multi-threaded code due to Amdahl’s law).
There is no reason (that I know of) for Mill to suck, and there is no reason (that I know of) why an implementation of the Mill architecture (if any ever actually exist) can’t use speculative execution and can’t be just as vulnerable as all other implementations (of all other architectures) that use speculative execution.
To be more honest; I’d assume that the Mill team have a (partial?) design for an implementation of the Mill architecture and have found that this design is vulnerable to (some variation/s of) Spectre, and are busy fixing their design (in the same way that Intel and AMD and ARM and Apple are all fixing their designs); where the only real difference is that nobody will ever find out that Mill was “temporarily vulnerable” because no vulnerable CPUs were actually released (because no CPUs were released at all).
– Brendan
Edited 2018-05-23 09:15 UTC
Interesting that you conveniently left out the second part of my reply.
Read the associated article. You might learn something.
Don’t waste your time with another long winded reply. I’m not interested in your ‘corrections’; and I suggest others may not be interested in them filling up the thread either.
Edited 2018-05-24 14:11 UTC
I just want to know when we should expect the massive class action lawsuit for processors that now perform significantly worse due to hardware bugs.
Bink,
The frustration is well founded, however despite the flaws, is anyone claiming that these CPUs are not to spec?
With conventional bugs like the FDIV bug, those CPUs clearly failed to perform a documented function and were out of spec. But with these flaws, these CPUs could technically still be to spec. I’m not siding with intel (and others) here, but play devil’s advocate: do intel’s specs make any specific guaranties about performance or side channels that would render these CPUs out of spec? If anyone asserts that they are, then can you produce the official spec they are in violation of?
I guess it’s time to go back to my dual PPro setup with BeOS.
Pentium Pro is when all of these vulnerabilities were introduced.
You’ll need to go back further. Pentium 1 should be safe, especially if you disable the V pipe.