Description of problem: Please close this bug if I am wrong or it is no longer true. - /dev/random uses too many entropy and blocks - /dev/urandom does not really consumes the entropy, but does not even blocks when the entropy pool is too low for crypto getrandom() works like urandom after enough entropy collected, but it blocks until a certain amount of entropy not acquired. The getrandom() is fast and secure for 99.99999999% of the cases. Practically, the /dev/urandom might be good enough, but only getrandom(2) has some short of guarantee for minimum entropy. Typically there is not much difference between getrandom() and urandom long time after the system booted, but a guest might be started at early boot time, where /dev/urandom usage can be bad.
A series intoducing getrandom() is floating around and can be used as a base to implement this in rng-random backend: [v3,00/23] Add qemu_getrandom and ARMv8.5-RNG etc https://patchwork.kernel.org/cover/10854035/
I have proposed a series to introduce a new RNG backend using builtin QEMU function qemu_guest_getrandom(): [v4,0/3] rng-builtin: add an RNG backend that uses qemu_guest_getrandom() https://patchwork.ozlabs.org/cover/1099309/ qemu_guest_getrandom() is defined in: [v6,00/25] Add qemu_getrandom and ARMv8.5-RNG etc https://patchwork.ozlabs.org/cover/1098227/ This series generates crypto quality numbers from the host and the source depends on QEMU build time configurationn: gcrypt (gcry_randomize()), gnutls (gnutls_rnd()), getrandom(), /dev/urandom or /dev/random (in this order of preference). A deterministic mode is available (with -seed parameter) and uses glib's Mersenne Twister (g_rand_int()).
I've included in my series the one from Kashyap that replaces /dev/random by /dev/urandom: [v6,1/4] VirtIO-RNG: Update default entropy source to `/dev/urandom` https://patchwork.ozlabs.org/patch/1102815/ In: [v6,0/4] rng-builtin: add an RNG backend that uses qemu_guest_getrandom() https://patchwork.ozlabs.org/cover/1102811/ Series "Add qemu_getrandom and ARMv8.5-RNG etc" is now part of QEMU master.
The commit to change to /dev/urandom is now merged in QEMU and will be in qemu-4.1: a2230bd778d8 VirtIO-RNG: Update default entropy source to `/dev/urandom` https://github.com/qemu/qemu/commit/a2230bd778d8445231d2120b87be3ed262bb4f8a
Series is now upstream (will be part of qemu-4.2.0): 6c4e9d487fea rng-builtin: add an RNG backend that uses qemu_guest_getrandom() 5f7655f6ef15 virtio-rng: Keep the default backend out of VirtIORNGConf 0198c2621a1e virtio-rng: change default backend to rng-builtin
Sanity testing with qemu-kvm-core-4.2.0-1.module+el8.2.0+4793+b09dd2fb.x86_64: 1. # man qemu-kvm -object rng-builtin,id=id Creates a random number generator backend which obtains entropy from QEMU builtin functions. The id parameter is a unique ID that will be used to reference this entropy backend from the virtio-rng device. By default, the virtio-rng device uses this RNG backend. 2. Boot VM with rng-builtin backend virtio-rng device: 2.1 CMD: """ /usr/libexec/qemu-kvm \ ... -object rng-builtin,id=obj0 \ -device virtio-rng-pci,rng=obj0,id=rng0,bus=pci.3,addr=0x0 \ """ 2.2 No related error info in dmesg. 2.3 Can find rng device in 'lspci' and '/sys/devices/virtual/misc/hw_random/rng_current'. 2.4 Execute 'dd if=/dev/random of=/dev/null bs=10 count=100' successfully. Hi Laurent, Are above steps enough for verifying? Is this only for qemu 4.2? What about qemu 4.1, qemu 3*, and qemu 2*? Thanks, yduan
(In reply to yduan from comment #11) > Sanity testing with > qemu-kvm-core-4.2.0-1.module+el8.2.0+4793+b09dd2fb.x86_64: > > 1. # man qemu-kvm > -object rng-builtin,id=id > Creates a random number generator backend which obtains > entropy from QEMU builtin functions. The id > parameter is a unique ID that will be used to reference this > entropy backend from the virtio-rng > device. By default, the virtio-rng device uses this RNG > backend. > > 2. Boot VM with rng-builtin backend virtio-rng device: > 2.1 CMD: > """ > /usr/libexec/qemu-kvm \ > ... > -object rng-builtin,id=obj0 \ > -device virtio-rng-pci,rng=obj0,id=rng0,bus=pci.3,addr=0x0 \ > """ > 2.2 No related error info in dmesg. > 2.3 Can find rng device in 'lspci' and > '/sys/devices/virtual/misc/hw_random/rng_current'. > 2.4 Execute 'dd if=/dev/random of=/dev/null bs=10 count=100' successfully. > > Hi Laurent, > > Are above steps enough for verifying? Perhaps you could also check visually the result "looks" random with something like "hexdump -C /dev/random" > Is this only for qemu 4.2? What about qemu 4.1, qemu 3*, and qemu 2*? Only for 4.2 New features are generally not backported to previous revisions (only bugfix).
# hexdump -C /dev/random 00000000 e4 56 f6 7b 5f 8a f8 75 1c 95 d4 ef 74 59 a9 62 |.V.{_..u....tY.b| 00000010 6b c8 6f 4f 42 f0 f5 7f fe 77 26 ec 42 81 5d cb |k.oOB....w&.B.].| 00000020 f4 8f a1 54 5b af e0 8f 32 4f 31 ee 5b f2 96 04 |...T[...2O1.[...| 00000030 05 2a 20 0c 81 2a e3 98 a0 97 54 25 fe 5e 95 0d |.* ..*....T%.^..| 00000040 fc 42 c2 47 d8 a0 23 0e 42 cd e5 16 10 6e 02 08 |.B.G..#.B....n..| 00000050 85 58 93 01 e4 6c 0e c4 c4 1b 89 5f 16 ac 42 75 |.X...l....._..Bu| 00000060 e7 4c 61 01 ee 32 83 fc 33 c6 00 31 25 55 67 d0 |.La..2..3..1%Ug.| 00000070 30 93 b5 0e 5d bc a0 c0 ab 99 a7 e1 61 c2 54 44 |0...].......a.TD| 00000080 d1 db ed df a7 98 4e da 2e 48 dd 05 46 17 29 16 |......N..H..F.).| 00000090 32 23 96 84 12 2a 68 eb 18 19 c8 fc 5c 2a 43 29 |2#...*h.....\*C)| 000000a0 31 14 e6 60 cc 9c 8a 45 2e cc 66 77 0e da 7b 04 |1..`...E..fw..{.| 000000b0 ed 32 53 90 bb a8 38 78 ca ee 4d 5a e1 2a d8 a0 |.2S...8x..MZ.*..| 000000c0 b8 a5 0b 22 a2 5e 53 52 31 68 fe 5b dc 52 08 57 |...".^SR1h.[.R.W| 000000d0 a7 48 af bd cb b0 5f 29 08 21 5b 8c 98 c7 62 ed |.H...._).![...b.| 000000e0 66 ff cb 3b 59 eb 48 d7 5b 34 90 1e b1 b6 0a 48 |f..;Y.H.[4.....H| 000000f0 3f 23 87 59 d4 d3 01 22 85 32 69 af 2c 58 b3 21 |?#.Y...".2i.,X.!| ......
Change to VERIFIED according to Comment 11, Comment 12 and Comment 13.
Hey, I think the device hot-plug/hot-unplug is missing here, which should be like: ➜ ~ virsh qemu-monitor-command 2 '{ "execute": "object-add","arguments": { "qom-type": "rng-builtin", "id": "rng-buildin-1"}}' {"return":{},"id":"libvirt-369"} ➜ ~ virsh qemu-monitor-command 2 --hmp device_add virtio-rng-pci,rng=rng-buildin-1,id=rng1,bus=pci.19,addr=0x0 ➜ ~ virsh qemu-monitor-command 2 --hmp info pci|grep rng1 -B5 Bus 20, device 0, function 0: Class 0255: PCI device 1af4:1044 PCI subsystem 1af4:1100 IRQ 0. BAR4: 64 bit prefetchable memory at 0xfc600000 [0xfc603fff]. id "rng1" ➜ ~ virsh qemu-monitor-command 2 --hmp device_del rng1 ➜ ~ virsh qemu-monitor-command 2 '{ "execute": "object-del","arguments": { "id": "rng-buildin-1"}}' {"return":{},"id":"libvirt-383"} ➜ ~ virsh qemu-monitor-command 2 --hmp info pci|grep rng1 -B5 Please check and test it by raw qemu
(In reply to Han Han from comment #15) > Hey, I think the device hot-plug/hot-unplug is missing here, which should be > like: > ➜ ~ virsh qemu-monitor-command 2 '{ "execute": "object-add","arguments": { > "qom-type": "rng-builtin", "id": "rng-buildin-1"}}' > {"return":{},"id":"libvirt-369"} > > > > > > ➜ ~ virsh qemu-monitor-command 2 --hmp device_add > virtio-rng-pci,rng=rng-buildin-1,id=rng1,bus=pci.19,addr=0x0 > > ➜ ~ virsh qemu-monitor-command 2 --hmp info pci|grep rng1 -B5 > Bus 20, device 0, function 0: > Class 0255: PCI device 1af4:1044 > PCI subsystem 1af4:1100 > IRQ 0. > BAR4: 64 bit prefetchable memory at 0xfc600000 [0xfc603fff]. > id "rng1" > > ➜ ~ virsh qemu-monitor-command 2 --hmp device_del rng1 > > > ➜ ~ virsh qemu-monitor-command 2 '{ "execute": "object-del","arguments": { > "id": "rng-buildin-1"}}' > {"return":{},"id":"libvirt-383"} > > ➜ ~ virsh qemu-monitor-command 2 --hmp info pci|grep rng1 -B5 > > > Please check and test it by raw qemu Thanks for your reminding. We used sanity testing to verify this bz. And we covered the hotplug/unplug operations in the following RHEL 8.2-fast fully test runs.
Hi Laurent, I don't find a libvirt bz to track this new backend. Do we need to file a new one for libvirt? Thanks, yduan
No libvirt patches or bug found. Filed a new one: bz1785091.
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2017