None of our customer-hosting systems are vulnerable to a SRBDS Crosstalk/SRBDS side-channel attack announced today.
This comes down to sheer luck on our end. Before this announcement, we were already actively planning to migrate away from Intel processors and will continue down that path.
In Ivy Bridge and newer Intel processors, there is an onboard random number generator. Truly random numbers are required for many security algorithms. For some Intel processors, it is hypothethically possible to leak information from one core to another from that random number generator because there is a shared buffer between all the physical cores. The full list of processors is here. Note that desktop and server models from the same microarchitecture may not have the same vulnerabilities.
Intel released a microcode update to mitigate this vulnerability. They also state that there is a significant performance impact, which suggests that disabling it may be a better option since most software using the Intel RNG was written using the assumed performance from before the mitigations.
There has long been speculation that the Intel RNG is not safe to use, but for a different reason. Mostly this was in the context of the RNG potentially being backdoored by a nation-state. Back in 2013 The FreeBSD Security Working Group recommended not using the Intel RNG as the sole source of entropy.
The Linux kernel, and presumably most other operating systems, will “mix” entropy provided by the Intel RNG with other sources. It is also already possible in the Linux kernel to disable use of Intel RNG with the nordrand kernel command line option. However this does not prevent user space from using the Intel RNG.
Under both Xen and KVM, it is possible to disable exposing the Intel RNG (rdrand) feature. For Xen, in the xl config file this could be:
And for KVM, if calling qemu directly this could be:
You can confirm this was properly applied by running:
grep -E 'rdrand|rdseed' /proc/cpuinfo
In the guest afterwards.