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

Following today's disclosure by Intel of the CrossTalk/SRBDS vulnerability that is MDS-based and vulnerable across physical cores with affected instructions, Intel released new CPU microcode to mitigate the most prone/significant instructions. I've been benchmarking the impact of this new microcode on multiple systems and will have a full report tonight or tomorrow morning... But here is a look specifically at the look at the impact on the RdRand performance.

RDRAND, RDSEED, and EGETKEY are the instructions currently being mitigated with the new microcode. As explained in the earlier article, mitigating CrossTalk involves locking the entire memory bus before updating the staging buffer and unlocking it after the contents have been cleared. This locking and serialization now involved for those instructions is very brutal on the performance, but thankfully most real-world workloads shouldn't be making too much use of these instructions.

The formal benchmarks I have running on three systems at the moment are comprised of both synthetic and real-world tests. But as a teaser here is a look at the RdRand performance impact itself using the well known Stress-NG kernel micro-benchmarks. The only change before/after on this Intel Xeon system was updating to the newly-released CPU microcode.

RdRand is now at ~3% the original speed for this hardware random number generator instruction for this Intel Xeon system. With other systems in looking at the RdRand performance, I am seeing similar massive penalties, but fortunately less so for more real-world workloads.

Linux kernel patches were also posted a short time ago for hitting the stable kernel series that when using this new CPU microcode will allow disabling the Special Register Buffer Data Sampling mitigation. Booting with mitigation=off on a patched kernel will allow disabling the SRBDS mitigation or if just wanting to disable this new microcode-based mitigation while keeping the other CPU security mitigations enabled, srbds=off is also to be supported by the forthcoming kernel series. With these new patches, the status will also be reported via /sys/devices/system/cpu/vulnerabilities/srbds.

Intel's formal guidance on Special Register Buffer Data Sampling notes that most client systems do not see enough RdRand/RDSEED/EGETKEY to warrant a significant performance impact but that 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, or where RDRAND/RDSEED is mixed with other entropy sources.

Stay tuned for the full set of CrossTalk / Special Register Buffer Data Sampling mitigation benchmarks tonight or tomorrow. For those that appreciate my relentless benchmarking, you can show your support by joining premium, making a PayPal tip, or foregoing any ad-block usage on this site.

UPDATE: More SRBDS benchmarks.