Hello. I'm a distro maintainer and was wondering about the efficacy of entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the authors of haveged [0] pointed out if the hardware cycles counter is emulated and deterministic, and thus predictible. He therefore does not recommend using HAVEGE on those systems. Is this the case with KVM's counters?

PS. I will be setting VM CPU settings to host-passthrough. Bonus: Also if anyone knows the answer to this question about Xen please let me know because its the other main platform we support and they don't have the luxury of virtio-rng in PVH mode. Thanks. [0] https://github.com/BetterCrypto/Applied-Crypto-Hardening/commit/cf7cef7a8... _______________________________________________ libvirt-users mailing list libvirt-users(a)redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users

Martin Kletzander: > On Fri, Aug 10, 2018 at 08:33:00PM +0000, procmem wrote: >> Hello. I'm a distro maintainer and was wondering about the efficacy of >> entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the >> authors of haveged [0] pointed out if the hardware cycles counter is >> emulated and deterministic, and thus predictible. He therefore does not >> recommend using HAVEGE on those systems. Is this the case with KVM's >> counters? >> > > I don't know the answer.  But try asking on qemu-discuss(a)nongnu.org or > maybe > KVM-related ML. > > Have a nice day, > Martin > Thanks. Yes I had already sent there. Waiting patiently for an answer :)

On Fri, Aug 10, 2018 at 08:33:00PM +0000, procmem wrote: > Hello. I'm a distro maintainer and was wondering about the efficacy of > entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the > authors of haveged [0] pointed out if the hardware cycles counter is > emulated and deterministic, and thus predictible. He therefore does not > recommend using HAVEGE on those systems. Is this the case with KVM's > counters? > > PS. I will be setting VM CPU settings to host-passthrough. Hardware from circa 2011 onwards has RDRAND support, and with host-passthrough this will be available to the guest. The rngd daemon, running in the guest, can use this as a source to feed the kernel entropy. In addition QEMU has support for virtio-rng which can pull entropy from /dev/urandom on the host, and feed it into the guest, where again rngd can give it to the kernel. So why do you need to consider haveged / jitterentropyd at all with QEMU ? It should suffice to just enable virtio-rng in the host and run rngd in all guests. If the host has RDRAND, that's an extra bonus. haveged / jitterentropyd should only be needed on other non-QEMU hypervisors which don't support something equiv to virtio-rng, and are on hardware that is too old for RDRAND. Regards, Daniel