PCPartPicker

  • Log In
  • Register

New Intel Vulnerability

Forum Search

Guidelines

  • Be respectful to others
  • No spam
  • No NSFW content
  • No piracy or key resellers
  • No link shorteners
  • Offensive content will be removed

Topic

CNCharger 1 month ago

https://www.youtube.com/watch?v=VUY5_GhE3rs

About as old as Spectre, but was not addressed till now and has not been fixed.

Comments Sorted by:

Gilroar 1 Build 3 points 1 month ago

Already covered in another post a couple days back why it isn't as big as the Hype machine makes it out to be and how they are wrong about it.

https://pcpartpicker.com/forums/topic/312001-spoiler-and-intel

About as old as Spectre, but was not addressed till now and has not been fixed.

SPECTRE effects and continues to effect everything using speculative execution. Spoiler only effects CPU with a specific cache style for Intel of Core and later.

They did not check anything AMD other then a Bulldozer based APU so Ryzen immunity isn't confirmed yet.

BetrayedPredator 2 points 1 month ago

To add to that, speculative execution is a massive part of any modern CPU

Without it you lose a ton of performance

yawumpus 1 point 1 month ago

SPECTRE is pretty toothless once you turn SMT (hyperthreading) off. Sure, it is possible to read some information from the previous thread, but you only get a short window during each thread change (unlike SMT operation). If you really want to avoid all of this, turn SMT off (possibly by buying a non-HT Intel chip).

Linus Torvalds said pretty much this (in the context of the difficulties in working around these issues in software) here:https://www.realworldtech.com/forum/?threadid=183825&curpostid=183854

So while there will always be theoretical attacks thanks to speculative execution (and you need it to get performance much better than a i486*), pretty much all of them take infinitely long once you turn off SMT. It all depends on which you care about more, that last 10-15% performance in highly threaded programs or security against untrusted code (mainly your browser on PCs).

Rowhammer seems baked into the DDR3/DDR4 spec (no idea how/if DDR5 will deal with it). Although spoiler may be an Intel specific way to get around modern mitigations of Rowhammer. Again, expect it to go away if you turn SMT off.

  • ok, a theoretical i486 running at a few hundred MHz with a modern L2/L3 cache. Or maybe just somewhat slower than the "little" ARM processor on a BIG/little phone CPU. But the performance hit is huge to avoid speculative execution.
Gilroar 1 Build 1 point 1 month ago

ok, a theoretical i486 running at a few hundred MHz with a modern L2/L3 cache. Or maybe just somewhat slower than the "little" ARM processor on a BIG/little phone CPU. But the performance hit is huge to avoid speculative execution.

Losing speculative execution would put the CPU in a cache miss state for anything not already being stored in caches. And is overvalued in SMT enabled designs where it has twice the impact.

It wouldn't nearly be enough to drop them that far back especially given there are later CPU then that which were not relying on that specific feature to the same extent as we see currently with far worse implementations of it.

Like I posted elsewhere here it would drop you back roughly into the later Bulldozer based performance range definitely not something desirable but also not the end of the world

yawumpus 1 point 1 month ago

Bulldozer definitely needed speculative execution. You should be able to design a Bulldozer without most of the SMT issues as well.

A missed branch prediction easily eats 10 cycles. The traditional assumption is that 1 out of 5 instructions involves a branch (that might be really old info), so ditching branch prediction could easily cut your IPC under 1/3. This alone is easily worse than any effect of turning off SMT. Between branch prediction and out-of-order execution, expect to lose an order of magnitude of performance by losing speculative execution. It just isn't comparable to SMT.

Gilroar 1 Build 1 point 1 month ago

Bulldozer definitely needed speculative execution. You should be able to design a Bulldozer without most of the SMT issues as well.

Bulldozer was merely a comparison of how much performance you would be losing off of a Lake or Zen architecture performance core which wouldn't be able to be used anymore.

A missed branch prediction easily eats 10 cycles. The traditional assumption is that 1 out of 5 instructions involves a branch (that might be really old info), so ditching branch prediction could easily cut your IPC under 1/3. This alone is easily worse than any effect of turning off SMT. Between branch prediction and out-of-order execution, expect to lose an order of magnitude of performance by losing speculative execution. It just isn't comparable to SMT.

Current architectures are running around 30% miss rate already counting incorrect executions that are discarded which can eat up way more then 10 clock cycles per miss.

Flipping to a completely hard compute style frees up all the resources and clock cycles already devoted to speculative executions of all styles as well as increasing the available instruction pathways for system use that had been devoted to purely speculative work.

Most of the current justification for keeping speculative is based on how much disabling it from current architectures costs not how much a architecture built without it performs.

CNCharger submitter 1 point 1 month ago

They did actually. The University that found this cross checked AMD and ARM. They found NO such vulnerability in either. Intel CPUs are the only cpus with the spoiler vulnerability.

Gilroar 1 Build 1 point 1 month ago

Double check the white paper they checked one each AMD and ARM of older design which they already were aware didn't feature the necessary cache to enable the exploit.

https://arxiv.org/pdf/1903.00446.pdf

So since they tested knowing the needed feature which could be exploited wasn't present on the older A6 and ARM processors it was rigged, probably in order to get the Intel bug bounty money but since it only enables exploits to work faster and is not a true exploit itself they got nothing.

And remember Spoiler is only an enabler, the attacks it enables are already known to be working on AMD, ARM, and Intel. If you pull off a spoiler attack as they suggest you will breach any of the CPU, this just lets you break an Intel CPU faster then before.

CNCharger submitter 1 point 1 month ago

https://www.theinquirer.net/inquirer/news/3072107/spoiler-flaw-affects-all-intel-cpus What is affected is Intel Proprietary, meaning AMD and ARM could not be affected unless they are copycatting off of Intel (which they aren't, AMD and Intel are purchasing some of their components from ARM to make their processors). If anything, Intel is trying to copycat off of AMD so they can make lower priced processors that can compete with AMD, but have failed to do so. Also, Intel has changed one of their contracts to prevent benchmarking of their new CPUs about to come out. AMD didn't. This means Intel is not ready to showcase their new CPUs cause Spoiler will take away from the CPUs and no one will want to buy a new Intel CPU (I wouldn't, too darn expensive, can't buy a high end gpu if I buy intel parts on my current budget).

CNCharger submitter 1 point 1 month ago

Also, Intel cheated with 9000 series core processors. Most of them are simply a re release of 7000 series, including the i9 9980XE, which is almost exactly the same as the 7980XE, but tweaked to go just slightly faster in base clock speed and boost, but same components.

Gilroar 1 Build 2 points 1 month ago

Also, Intel cheated with 9000 series core processors.

Rather then fanboy stop and remember that AMD did the same with the 2000 series models first off.

Intel added in silicon fixes to remove vulnerabilities to some of the multiple SPECTRE exploits. They are the first company to begin adding mitigations although AMD and ARM have announced models which also are doing the same.

Gilroar 1 Build 1 point 1 month ago

Reread the whitepaper they published on the subject linked above.

And again.

https://arxiv.org/pdf/1903.00446.pdf

The only reason the AMD and ARM tested wasn't effected is both lack a modern cache system because they are older products and they only tested a single of each unlike with Intel where they tested multiple models.

Spoiler and pun intended on that both ARM and AMD have copied Intels caching design with newer products like Ryzen.

This whole thing is worse then the CTS labs where remember they had actual independently verified exploits unlike here where they have no verification and they didn't test anything modern for the companies they say are immune.

To top it all off the exploit does nothing without using attacks which all three manufacturers are vulnerable currently.

Spoiler changes absolutely nothing with or without it on any of the three companies CPU the end result is the same you lost information to the exploits because all three are vulnerable.

CNCharger submitter 1 point 1 month ago

The Ryzen 2000 series knocks 1000 series out of the park. Its a new architecture. Zen and Zen+ are NOT the same. I also searched for info on Ryzen being vulnerable to Spoiler, and not a thing has come up. I reread the article and checked the PDF and while yes, the AMD CPUs and ARM CPUs tested are old, the affected part is only owned and produced by Intel, not AMD or ARM. But now I guess we will wait and see if Ryzen experiences any issues. Also, if ARM makes desktop processors, why aren't they on here?

[comment deleted]
Allan_M_Systems 3 points 1 month ago

With this and other vulnerabilities coming to light... I wonder what the future of computing will bring if Intel and AMD are forced to crack down, at a hardware level, on all these "sneak paths" for observing data in flight from user space.

I wonder if we are in for a regression in CPU performance to close these security holes, or if they come up with a way to perhaps encrypt a lot more of the data in caches, in memory, in flight, etc.... Spoiler isn't the first unsolved security flaw in SMT designs, and probably won't be the last.

Gilroar 1 Build 2 points 1 month ago

Google is already pushing that there is a need to get rid of SMT and Speculative Execution since they cannot be locked down.

At least in theory removing those from the playing field puts things back to Bulldozer type performance levels. Generally an undesirable situation but not necessarily the end of the world.

Allan_M_Systems 2 points 1 month ago

Makes me wonder.... Maybe AMD's direction on Bulldozer had merits that weren't obvious at the time. Curious about whether security was part of the driving factor on that design or if it really was just a blunderous misunderstanding of how to scale up performance that accidentally has fewer security issues.

Gilroar 1 Build 2 points 1 month ago

That I don't know but it was based on a server design so it could have been a measure of both.

Allan_M_Systems 2 points 1 month ago

Atom / Kabini / Jaguar....

I wonder if we see those "small core" programs brought into the mainstream with many-core variants as security driven architectures targeted towards business and the server industry.

Right now, these are limited to low power low cost system deployments, but I wonder if we see the "splitting" point move in the coming years.

Gilroar 1 Build 1 point 1 month ago

I think they would likely move towards scaling up those simpler easier to ruggedize designs into full fledged cores.

But then again Intel is moving towards ARMs big/LITTLE design so all bets are off on that point of view.

yawumpus 1 point 1 month ago

I doubt Google will ever buy CPUs that don't include speculative execution (at least for their major servers). Losing SMT is probably something they can afford (it will hurt, but probably less than all the work needed to avoid Spectre like attacks).

Including speculative attacks serves two possible purposes: to fix a cost in peoples minds to then make "turning off SMT" that much more appealing, or possibly to promote Google's new AI chip, which probably doesn't have any speculative execution at all. Of course that one has a completely different security issue: since it wasn't "programmed" in the conventional sense, you really don't know how the bugs will manifest (and the training method was unlikely to avoid all the really bad cases).

CNCharger submitter 1 point 1 month ago

AMD is not vulnerable to Spoiler. Neither is ARM.

JCMsergox 4 Builds 1 point 1 month ago

Laughs in AMD

Gilroar 1 Build 2 points 1 month ago

I wouldn't laugh just yet.

This exploit only speeds up already known exploits which effect AMD as well.

And their testing as it were is even more of a blatant hit job then the CTS labs since they knowingly tested a single older AMD and ARM model which lacked the needed cache and wasn't going to be effected.