There are some ways, although that doesn't mean they're always used.
I read this week QEMU has provides a virtio RNG device to the guest, that reads from the host. That's good. What I'm less clear about is other hypervisors, or whether x86 hypervisors tend to provide RDRAND support.
> or whether x86 hypervisors tend to provide RDRAND support.
One issue that I've been wondering about is how safe this is. Presumably you can't let a VM use the RDRAND directly because it could starve the entropy of other VMs. Assuming that presumption is true, a hypervisor would need to manage that shared resource fairly amongst the VMs.
I don't know this for sure, but I'm not under the impression that RDRAND has the same "entropy as a scarce resource" or "block waiting on entropy" issue that the Linux apis have.
RDSEED is actually what people want most of the time. RDRAND may return before sufficient entropy has been gathered.
Basically, RDRAND was made first to be something like a hardware /dev/urandom. Of course, people started using RDRAND to generate RSA-keys or whatever, but the entropy may be depleted between uses.
So you're supposed to use RDSEED whenever you need something that'd actually be truly random with a full set of entropy.
Yes but RDRAND is easy to hide. No test can tell the difference between a good and a backdoored RNG, you don't know what to look for, the whole point of randomness is that you don't know what it will do, so you can only trust reasoning based on understanding where the numbers come from.
I'm pretty sure rdrand is fine, and would not bat an eye if Linux trusted it, but I'm not sure I would bet some nuclear launch codes on it. Linux is trying to be as safe as practically possible, not just "Probably safe".
There are some ways, although that doesn't mean they're always used.
I read this week QEMU has provides a virtio RNG device to the guest, that reads from the host. That's good. What I'm less clear about is other hypervisors, or whether x86 hypervisors tend to provide RDRAND support.