Bug 1389469

Summary: virtio-rng /dev/random drains entropy from host desktop
Product: [Fedora] Fedora Reporter: Oliver Henshaw <oliver.henshaw>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: agedosier, amit.shah, berrange, cfergeau, clalancette, dwmw2, itamar, laine, libvirt-maint, pbonzini, rjones, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-25 10:27:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
'ps aux' after booting into runlevel 's' and logging in
none
'perf record -e random:debit_entropy -e random:credit_entropy_bits --call-graph dwarf -a -D 1000 -T sleep 120; perf script' output on host when booted into runlevel 's'
none
'ps aux' after booting into runlevel '3' and logging in
none
'perf record -e random:debit_entropy -e random:credit_entropy_bits --call-graph dwarf -a -D 1000 -T sleep 120; perf script' output on host when booted into runlevel '3'
none
perf record -e random:debit_entropy -e random:credit_entropy_bits --call-graph dwarf -a -D 1000 -T sleep 120; perf script' output on guest when booted into runlevel '3' none

Description Oliver Henshaw 2016-10-27 16:02:05 UTC 
Description of problem:

I currently need to add a virtual RNG (backed by /dev/random) to quickly boot updated fedora 24 desktop images (on an F23 desktop host) - see bug 1212082 comment #21. But I noticed that this tends to drain entropy from the host, so that typically the guest has much more entropy than the host.

Typical values might be:

[host]# cat /proc/sys/kernel/random/entropy_avail
807
$ Boot guest desktop in VM
[host]# cat /proc/sys/kernel/random/entropy_avail 
50
[guest]# cat /proc/sys/kernel/random/entropy_avail 
1095

If I add 's' to the grub boot parameters, host entropy takes a one-time hit but rises back to its original value. If instead I boot into run-level '3' the host stays at double-digit entropy indefinitely and the guest may eventually end up with more entropy than the host's baseline level.

Version-Release on host:

qemu-2.4.1-11.fc23.x86_64
virt-manager-1.3.2-2.fc23.noarch
libvirt-1.2.18.4-1.fc23.x86_64
spice-server-0.12.8-1.fc23.x86_64
kernel-4.7.9-100.fc23.x86_64

Version-Release on guest:

kernel-4.7.9-200.fc24.x86_64
spice-vdagent-0.16.0-3.fc24.x86_64
Comment 1 Oliver Henshaw 2016-10-27 16:07:42 UTC 
Created attachment 1214667 [details]
'ps aux' after booting into runlevel 's' and logging in
Comment 2 Oliver Henshaw 2016-10-27 16:14:05 UTC 
Created attachment 1214668 [details]
'perf record -e random:debit_entropy -e random:credit_entropy_bits --call-graph dwarf -a -D 1000 -T sleep 120; perf script' output on host when booted into runlevel 's'

No mouse or keyboard activity on the host, so this is a little pessimistic but (a) it makes the output smaller, (b) it makes no difference to the entropy drain on the host.

qemu-system-x86_64 occasionally takes 512 bits from the host, but it can easily replace the entropy.
Comment 3 Oliver Henshaw 2016-10-27 16:15:09 UTC 
Created attachment 1214669 [details]
'ps aux' after booting into runlevel '3' and logging in
Comment 4 Oliver Henshaw 2016-10-27 16:18:39 UTC 
Created attachment 1214671 [details]
'perf record -e random:debit_entropy -e random:credit_entropy_bits --call-graph dwarf -a -D 1000 -T sleep 120; perf script' output on host when booted into runlevel '3'

No mouse or keyboard activity on the host, so this is a little pessimistic but (a) it makes the output smaller, (b) it makes no difference to the entropy drain on the host.

Now qemu-system-x86_64 is frequently extracting small amounts of entropy from the host and the host entropy pool doesn't recover to its original level.
Comment 5 Richard W.M. Jones 2016-10-27 16:22:04 UTC 
You can (and should) back virtio-rng with /dev/urandom instead.
However it requires libvirt >= 1.3.4 which might require Fedora 24+.

https://www.redhat.com/archives/libvir-list/2016-April/msg00987.html
Comment 6 Oliver Henshaw 2016-10-27 16:24:04 UTC 
Created attachment 1214672 [details]
perf record -e random:debit_entropy -e random:credit_entropy_bits --call-graph dwarf -a -D 1000 -T sleep 120; perf script' output on guest when booted into runlevel '3'

Simultaneous with attachment #1214671 [details]. There seems to be very little debiting the entropy pool. Credits only come 1 bit at a time for the most part, it doesn't seem like this matches the entropy debit on the host?
Comment 7 Fedora End Of Life 2016-11-25 09:38:29 UTC 
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 8 Richard W.M. Jones 2016-11-25 10:27:02 UTC 
I think we can say this is fixed, but it requires Fedora 24+

Fedora 23 has libvirt 1.2.18 which doesn't have the fix, and
I don't think libvirt has any plans to rebase since F23 is about
to become obsolete.