Linked by Thom Holwerda on Mon 21st May 2018 22:52 UTC
Bugs & Viruses

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.

Thread beginning with comment 657185
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Backwards evolution
by bhtooefr on Wed 23rd May 2018 07:51 UTC in reply to "RE[2]: Backwards evolution"
bhtooefr
Member since:
2009-02-19

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

Reply Parent Score: 2

RE[4]: Backwards evolution
by Alfman on Wed 23rd May 2018 14:02 in reply to "RE[3]: Backwards evolution"
Alfman Member since:
2011-01-28

bhtooefr,

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



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.

Reply Parent Score: 3