News Intel Finds Bug in AMD's Spectre Mitigation, AMD Issues Fix

[Admin]

Intel's crack STORM security research team unearthed an issue with AMD's mitigations for the Spectre vulnerability that leaves users exposed to unhindered attackers. AMD has since changed its recommendations to a new type of mitigation.

Intel Finds Bug in AMD's Spectre Mitigation, AMD Issues Fix : Read more

 

[The_King]

When can we expect new Benchmarks to show just how much the performance difference there is now, between Intel and AMD after the new Spectre V2 mitigation.

https://www.tomshardware.com/news/a...ance-drop-from-revised-spectre-v2-mitigations

 

[USAFRet]

When can we expect new Benchmarks to show just how much the performance difference there is now, between Intel and AMD after the new Spectre V2 mitigation.

https://www.tomshardware.com/news/a...ance-drop-from-revised-spectre-v2-mitigations

With all the previous mitigations, how much performance change did we see?

 

[TerryLaze]

When can we expect new Benchmarks to show just how much the performance difference there is now, between Intel and AMD after the new Spectre V2 mitigation.

https://www.tomshardware.com/news/a...ance-drop-from-revised-spectre-v2-mitigations

Take a look inside the article, don't go by the headline alone, epyc is only impacted by about 10% while the 5950x is upto™ 54% and that is in context-switching which is heavily used in games and even more so when gaming while doing more stuff on your PC at the same time.

The Ryzen 9 5950X (Vermeer) suffered a 54% performance reduction with the Stress-NG (Context Switching) benchmark.

Compared to the Ryzen 9 5950X, the Ryzen 9 5900HX (Cezanne) wasn't affected as much with Stress-NG. The mobile Zen 3 chip only saw 22% lower performance.


with the EPYC 72F3, Phoronix only logged 8.9% lower networking performance and 7.2% lower storage performance.

 

[Deleted member 431422]

Which of these Spectre, and other, vulnerabilities can be executed remotely and have been seen to be used? It's starting to look like a PR war to me at the moment.

 

[hotaru.hino]

Which of these Spectre, and other, vulnerabilities can be executed remotely and have been seen to be used? It's starting to look like a PR war to me at the moment.

On one hand yes. On the other, a vulnerability with potentially severe consequences if exploited should be patched if there's an actual way to exploit it, regardless of how feasible it is do so. It's a known vulnerability, someone's going to use it for bad purposes.

 

[domih]

Take a look inside the article, don't go by the headline alone, epyc is only impacted by about 10% while the 5950x is upto™ 54% and that is in context-switching which is heavily used in games and even more so when gaming while doing more stuff on your PC at the same time.

The chip is going down! Save the children! AMD is dead before the end of the week!

Mmm... Let's be real and use some facts.

I tested before and after the patches with Passmark and then with a more real life workload(*) on my TR 3960X as well as my 5950X. In both cases Passmark (CPU and Memory tests) speed degradation was less than 1% and the real life workload speed degradation was less than 3%. Tested on Ubuntu 20.04 LTS.

(*) A complete unit-testing run on a project from work that takes 10 minutes to complete (heavy computation, crypto security and database).

I don't use Windows so I let another good Samaritan do the same thing on Win 10 and Win 11.

This is consistent with what Phoronix found and published (see https://www.phoronix.com/scan.php?page=article&item=amd-retpoline-2022&num=1).

Tom's Hardware reports the same (see https://www.tomshardware.com/news/a...ance-drop-from-revised-spectre-v2-mitigations)

Meanwhile BHI / Spectre-BHB affects INTEL and ARM, but so far AMD is not considered affected.

CONCLUSION: from my seat, with AMD, it's a non story. The children are fine. The Sun rose this morning.

 

[hotaru.hino]

Take a look inside the article, don't go by the headline alone, epyc is only impacted by about 10% while the 5950x is upto™ 54% and that is in context-switching which is heavily used in games and even more so when gaming while doing more stuff on your PC at the same time.

Stress-ng is also like prime95 in that it's a torture test. It's right there in the manpage:

stress-ng was originally intended to make a machine work hard and trip hardware issues such as thermal overruns as well as operating system bugs that only occur when a system is being thrashed hard. Use stress-ng with caution as some of the tests can make a system run hot on poorly designed hardware and also can cause excessive system thrashing which may be difficult to stop.

I would file this under an unrealistic test, much like prime95. It's only useful in seeing how the processor performs in extreme cases.

 

[TerryLaze]

Stress-ng is also like prime95 in that it's a torture test. It's right there in the manpage:

Yes but a stress test heavy in context switching which happens always no matter how many cores you have (because windows) , while prime is heavy in calculating prime numbers that ..is used?! Like at all?! ... Somewhere?!

 

[hotaru.hino]

Yes but a stress test heavy in context switching which happens always no matter how many cores you have (because windows) , while prime is heavy in calculating prime numbers that ..is used?! Like at all?! ... Somewhere?!

Context switching can be an expensive operation yes, but that means the scheduler is aware of this as well. Threads and processes don't simply swap in and out all the time, they only do that if they're ready to run. And considering that CPU % utilization on any given OS's resource manager (Task Manager, top, etc.) means how often the CPU did not run system idle task, a low CPU % utilization indicates to me there's not a lot of context switching going on.

Otherwise you're free to prove to us that the numbers stress-ng uses are the similar to that in a given user scenario.

 

[TerryLaze]

Context switching can be an expensive operation yes, but that means the scheduler is aware of this as well. Threads and processes don't simply swap in and out all the time, they only do that if they're ready to run. And considering that CPU % utilization on any given OS's resource manager (Task Manager, top, etc.) means how often the CPU did not run system idle task, a low CPU % utilization indicates to me there's not a lot of context switching going on.

Otherwise you're free to prove to us that the numbers stress-ng uses are the similar to that in a given user scenario.

If you are buying a 32 thread monster to have it sit idle that's up to you...
You can always just use it for cinebench and the like where there is zero context switching.