Red Hat Bugzilla – Bug 1579518
EFI_RNG_PROTOCOL no longer produced for virtio-rng
Last modified: 2018-10-30 05:38:02 EDT
*** Description of problem: The following upstream commits optimized OVMF and AAVMF boot times by narrowing down the set of connected (bound) boot devices as directed by QEMU's "bootorder" fw_cfg file: * 245c643cc8b7 ("OvmfPkg/PlatformBootManagerLib: minimize the set of connected devices", 2018-03-14) * ff1d0fbfbaec ("ArmVirtPkg/PlatformBootManagerLib: minimize the set of connected devices", 2018-03-14) Virtio RNG devices are never boot devices, thus the firmware stopped auto-connecting them in the above commits. This is a problem because an OS boot loader may depend on EFI_RNG_PROTOCOL to seed the OS's RNG. *** Version-Release number of selected component (if applicable): ovmf-20180508-1.gitee3198e672e2.el7 *** How reproducible: Always. *** Steps to Reproduce: 1. Add a virtio-rng device to the domain configuration -- may be virtio-mmio (AAVMF only), or virtio-pci (modern-only or legacy/transitional). 2. Set up firmware debug log capture, *OR* boot a guest OS that reports whether it managed to get entropy from EFI_RNG_PROTOCOL. *** Actual results: * With the debug log captured, the following message is missing: > InstallProtocolInterface: 3152BCA5-EADE-433D-862E-C01CDC291F44 ... The above GUID stands for EFI_RNG_PROTOCOL. * If an aarch64 kernel is booted, its UEFI stub reports > EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied *** Expected results: The "InstallProtocolInterface" line about EFI_RNG_PROTOCOL should be present in the debug log, and (given a suitable kernel), the UEFI stub's complaint should disappear.
Domain XML fragments for testing this: * virtio-mmio (AAVMF only): <rng model='virtio'> <rate bytes='1048576'/> <backend model='random'>/dev/urandom</backend> <address type='virtio-mmio'/> </rng> * virtio-pci legacy (both AAVMF and OVMF) -- plug the device in the root complex: <rng model='virtio'> <rate bytes='1048576'/> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </rng> * virtio-pci modern (both AAVMF and OVMF) -- plug the RNG device in a root port: <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x8'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> </controller> <rng model='virtio'> <rate bytes='1048576'/> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </rng>
Posted upstream patch series: [edk2] [PATCH 0/2] ArmVirtPkg, OvmfPkg: connect Virtio RNG devices again http://mid.mail-archive.com/20180518062026.2781-1-lersek@redhat.com https://lists.01.org/pipermail/edk2-devel/2018-May/024861.html
Upstream commits: 1 c4add6b6e971 ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG devices again 2 7ebad830d6ab OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices again
Fix included in ovmf-20180508-2.gitee3198e672e2.el7
Reproduced bug with OVMF-20180508-1.gitee3198e672e2.el7. result: #grep -i 3152BCA5-EADE /home/test/ovmf1.log nothing Verified bug with OVMF-20180508-2.gitee3198e672e2.el7.noarch # grep -i 3152BCA5-EADE /home/test/ovmf1.log InstallProtocolInterface: 3152BCA5-EADE-433D-862E-C01CDC291F44 7E001210 This is qemu cli. /usr/libexec/qemu-kvm -enable-kvm -M q35 -nodefaults -smp 4,cores=2,threads=2,sockets=1 -m 4G -name vm1 -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw,unit=1,readonly=on -debugcon file:/home/test/ovmf1.log -global isa-debugcon.iobase=0x402 -spice port=5933,disable-ticketing -vga qxl -monitor stdio \ -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,id=rng-device0 \ -boot menu=on,splash-time=10000 -drive file=/mnt/rhel75-64-secure-boot.qcow2,if=none,id=guest-img,format=qcow2,werror=stop,rerror=stop -device virtio-blk-pci,drive=guest-img,id=os-disk,bootindex=0 -netdev tap,id=hostnet0,vhost=on -device rtl8139,netdev=hostnet0,id=net0,mac=00:84:ed:01:00:05 This bug is fixed. set it as verified. If need to test scenario. please let me know.
Hi FuXiangChun, the testing looks sufficient to me. 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/RHSA-2018:3090