RdRand Performance As Bad As ~3% Original Speed With CrossTalk/SRBDS Mitigation

[ryao]

I wonder if only the threads using rdrand are affected or other threads will slow down because of rdrand being called. If it Is the latter, this would be a potential DoS attack. :/

[angrypie]

This is what happens when you skip bounds checking to get an unfair advantage over a competitor.

[Spacefish]

I wonder if only the threads using rdrand are affected or other threads will slow down because of rdrand being called. If it Is the latter, this would be a potential DoS attack. :/

Probably yes, as this locks the memory bus .. Could imagine the having a big impact on games/game servers, where the instruction is used to generate randomness in high frequency.

The really bad thing about this specular execution vulnerability is, that it leaks information between physical cores!! So a mitigation for VMs where you pin a VM on one core and the other on another for example, won´t work. This sets it appart from all the other currently known speculative execution bugs.
As Intel has often a homogenous chip design, this won´t even effect just a "cluster" but probably all cores on one die / processor.

[Ahmad_S792]

There is another vulnerability similar to CacheOut:

https://sgaxe.com/

[torsionbar28]

Ouch. Just ouch. And it is microcode so it will affect everything that makes use of RdRand.
Either that slipped through testing or it is inevitable.
Either way: Ouch.

Ouch is right. And how about this pile of intel BS:

workloads more common to servers may be impacted. Intel supports system administrators disabling the mitigation if no untrusted software is running on the software, if RDRAND/RDSEED is only used where the random value is not important for security

What kind of server workloads exist, that are making extensive use of random values for something NOT security related? What a joke. What's next, they're going to find their AES-NI implementation is flawed, and will recommend using it only when you're encrypting data that is not sensitive? LMAO

[theriddick]

You would think Intel hw fix these issues in upcoming architecture like 10nm, but I hear their not, can't be bothered. ..

[torsionbar28]

You would think Intel hw fix these issues in upcoming architecture like 10nm, but I hear their not, can't be bothered. ..

Probably some of these vulnerabilities were already designed into the next uarch, and because it's already so far behind schedule, they don't want further delays for rework. It'll be another microcode performance mitigation. I'm guessing 2023 at the earliest, before intel ships a chip with all known (read: known as of today) vulns fixed in hardware.

[Imout0]

Where is Birdie to defend poor Intel?

[cynic]

You would think Intel hw fix these issues in upcoming architecture like 10nm, but I hear their not, can't be bothered. ..

from when you design an architecture to when it becomes physical product on the market it takes more or less 4/5 years. So, the bug discovered today aren't going to be fixed until then (unless they started design a completely new arch 4/5 years ago)

[Guest]

Ouch, this is bad. It's a different bug than the AMD RDRAND debacle but also makes RDRAND unusable. I'm curious to know if use of RDRAND will impact anything else running on the system.