Intel CPUs Reportedly Vulnerable To New "SPOILER" Speculative Attack

[nanonyme]

Ohh for fcuke sake, can we have a class action against Intel going? This is getting out of hand, purposely making chips vulnerable to hacks is surely a valid reason?

Probably. Why wait?

[JanW]

Intel received notice of this research, and we expect that software can be protected against such issues by employing side channel safe software development practices. This includes avoiding control flows that are dependent on the data of interest.

OK, noob question here: What do they mean by this? Avoid using "if" in any code running on my machine? No "switch"? No loops where the number of iterations depends on data? Surely I must be misunderstanding something.

[darkbasic]

Am I the only who doesn't notice any slowdowns with the mitigations enabled?

It depends on your workload, most are unaffected.

[noctrex]

as long as my MIPS64 Sgi Octane is safe all is well: https://www.youtube.com/watch?v=AU_RV8uoTIo

Sweet machine!

But it seems that even MIPS was affected, although on very limited CPUs:

https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/

[lucrus]

Everyone is hating on Intel CPUs when in reality almost all modern CPUs are effected by these flaws in microarchitecture design.
Spectre (all variants but Meltdown and Spoiler): AMD, Intel, Arm
Meltdown: Intel, Arm
SPOILER: Intel (at least for now).
The only one that's Intel specific is SPOILER which is new and has a possibility of being found on others as well. The bugs are with modern micro-architecture design, not soley with Intel's designs

While it is true that SPOILER is the only one specific to Intel, it's also true that Intel is the only one vulnerable to all of them. BTW, citing Meltdown as a Spectre variant is being fooled by Intel, who did announce the two vulnerabilities in the same document exactly to fool people into believing they are similar, but they are actually very different, in that expoiting Spectre is much harder than exploiting Meltdown.
I don't know about SPOILER yet, but if it's really Intel only, it can hardly be a Spectre variant.

[gamerk2]

While it is true that SPOILER is the only one specific to Intel, it's also true that Intel is the only one vulnerable to all of them. BTW, citing Meltdown as a Spectre variant is being fooled by Intel, who did announce the two vulnerabilities in the same document exactly to fool people into believing they are similar, but they are actually very different, in that expoiting Spectre is much harder than exploiting Meltdown.
I don't know about SPOILER yet, but if it's really Intel only, it can hardly be a Spectre variant.

Which makes sense, given Intel was a LOT more aggressive then AMD when it came to maximizing performance coming from speculative execution. It goes to follow there are a few more holes that were introduced as a result.

The fact remains though: Speculative execution will never be 100% secure in hardware; the question that needs to be asked is "how much performance am I willing to give up for a certain amount of extra security?"

[gamerk2]

To be reluctantly fair, most users don't want to pay for safety/security so it's not entirely Intel's fault. It's as much the fault of their customers as Intel's (including myself on some ocassions). Intel has largely delivered what their customers wanted. Cheap computing with a very strong backwards compatibility ethic. Only now we're getting the "past due" notice on the technical debt that was already in the mail over 20 years ago.

Adding after a moment thought: I wonder if or how much Itanium is vulnerable to speculative architecture attacks. I know POWER and ARM both have such vulnerabilities in their implementation.

From what I've been able to dig up, Itanium is immune to all these attack vectors due to it's pipeline being in-order. Basically, since it was designed to be massively parallel (something, ironically, we all want now) it's designers didn't need to put in all those speed-hacks that are now being exploited in x86.

Not the best source, but here's a high level overview: https://secure64.com/not-vulnerable-...ure64-sourcet/

So there *is* a quick-fix for Intel: Finally retire x86 as an architecture and move to Itanium. Which is what should have happened in the first place. x86-64 coming along was literally the worst thing that's happened to modern computing; x86 as an architecture needs to die.

[Weasel]

From what I've been able to dig up, Itanium is immune to all these attack vectors due to it's pipeline being in-order. Basically, since it was designed to be massively parallel (something, ironically, we all want now) it's designers didn't need to put in all those speed-hacks that are now being exploited in x86.

Not the best source, but here's a high level overview: https://secure64.com/not-vulnerable-...ure64-sourcet/

So there *is* a quick-fix for Intel: Finally retire x86 as an architecture and move to Itanium. Which is what should have happened in the first place. x86-64 coming along was literally the worst thing that's happened to modern computing; x86 as an architecture needs to die.

You know Itanium died for a reason. It's simply inferior to x86, don't be so butthurt.

The CPU can schedule instructions at runtime much better than a compiler can at compile time because it can take into account the taken branches, so it can vary for the same piece of code. You cannot do this statically. This is why Itanium flopped.

[Vistaus]

Sounds like you aren't doing anything intensive with your machine. The performance impact is real, and it's significant. We don't need to speculate (no pun intended) as Michael has benchmarked this a number of times now, so do a search to see the results. The performance impact is also dependent on the type of work. For some applications, it's only a few percents. For others, it's 20%+.

I do intensive stuff with my laptop. Vivaldi alone is a resource hog (but I do other stuff as well, even with Vivaldi opened in the background with quite a few tabs), but everything runs fine and smoothly.

[gamerk2]

You know Itanium died for a reason. It's simply inferior to x86, don't be so butthurt.

The CPU can schedule instructions at runtime much better than a compiler can at compile time because it can take into account the taken branches, so it can vary for the same piece of code. You cannot do this statically. This is why Itanium flopped.

Not true; Itanium outperformed x86 for pretty much it's entire lifecycle. The reason it flopped was because there was a 20% hit to legacy x86 applications due to emulating x86 in hardware, and AMD undercutting Intel with the bandaid that is x86-64.