procmem
2018-Aug-10 20:33 UTC
[libvirt-users] Efficacy of jitterentropy RNG on qemu-kvm Guests
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/cf7cef7a870c1b77089b1bd6209ded6525b5a4e0#commitcomment-23006392
Martin Kletzander
2018-Aug-16 13:04 UTC
Re: [libvirt-users] Efficacy of jitterentropy RNG on qemu-kvm Guests
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@nongnu.org or maybe KVM-related ML. Have a nice day, Martin>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/cf7cef7a870c1b77089b1bd6209ded6525b5a4e0#commitcomment-23006392 > >_______________________________________________ >libvirt-users mailing list >libvirt-users@redhat.com >https://www.redhat.com/mailman/listinfo/libvirt-users
Daniel P. Berrangé
2018-Aug-16 13:24 UTC
Re: [libvirt-users] Efficacy of jitterentropy RNG on qemu-kvm Guests
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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
procmem
2018-Aug-16 15:06 UTC
Re: [libvirt-users] Efficacy of jitterentropy RNG on qemu-kvm Guests
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@nongnu.org or > maybe > KVM-related ML. > > Have a nice day, > Martin >Thanks. Yes I had already sent there. Waiting patiently for an answer :)
procmem
2018-Aug-16 15:12 UTC
Re: [libvirt-users] Efficacy of jitterentropy RNG on qemu-kvm Guests
Daniel P. Berrangé:> 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 >Makes sense. Thanks for your answer.
Apparently Analagous Threads
- Re: Efficacy of jitterentropy RNG on qemu-kvm Guests
- Re: Efficacy of jitterentropy RNG on qemu-kvm Guests
- Re: Efficacy of jitterentropy RNG on qemu-kvm Guests
- getrandom waits for a long time when /dev/random is insufficiently read from
- getrandom waits for a long time when /dev/random is insufficiently read from