新的 CPU 漏洞又来了，又是与预测执行机制有关，又是主要影响英特尔处理器。Linux 内核主线刚刚合并了补丁或微码去缓解“特定寄存器缓冲器数据采样（Special Register Buffer Data Sampling或 SRBDS）”漏洞影响。Spectre、Meltdown 等预测执行攻击的补丁主要是应用于核心内部，新的漏洞允许攻击者跨核心泄露敏感信息。被称为 CrossTalk 的攻击允许攻击者控制一个 CPU 核心的代码执行，去泄露不同核心上的软件执行敏感数据。Phoronix 测试了微码对 RdRand 性能的影响，结果显示性能下跌达到了惊人的 97%，打了微码之后的 RdRand 得分只有原来的 3%。
RdRand Performance As Bad As ~3% Original Speed With CrossTalk/SRBDS MitigationWritten by Michael Larabel in Intel on 9 June 2020 at 03:58 PM
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.