1579518 – EFI_RNG_PROTOCOL no longer produced for virtio-rng

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1579518 - EFI_RNG_PROTOCOL no longer produced for virtio-rng

Summary: EFI_RNG_PROTOCOL no longer produced for virtio-rng

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	ovmf
Sub Component:
Version:	7.6
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Laszlo Ersek
QA Contact:	FuXiangChun
Docs Contact:
URL:
Whiteboard:
Depends On:	1577546
Blocks:
TreeView+	depends on / blocked

Reported:	2018-05-17 20:31 UTC by Laszlo Ersek
Modified:	2018-10-30 09:38 UTC (History)
CC List:	7 users (show)
Fixed In Version:	ovmf-20180508-2.gitee3198e672e2.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2018-10-30 09:36:07 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2018:3090	0	None	None	None	2018-10-30 09:38:02 UTC

Description Laszlo Ersek 2018-05-17 20:31:00 UTC

*** 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.

Comment 2 Laszlo Ersek 2018-05-18 05:48:52 UTC

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>

Comment 3 Laszlo Ersek 2018-05-18 06:21:17 UTC

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

Comment 4 Laszlo Ersek 2018-05-18 11:57:39 UTC

Upstream commits:

  1 c4add6b6e971 ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG
                 devices again
  2 7ebad830d6ab OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices
                 again

Comment 7 Miroslav Rezanina 2018-06-08 07:51:21 UTC

Fix included in ovmf-20180508-2.gitee3198e672e2.el7

Comment 9 FuXiangChun 2018-06-11 09:58:35 UTC

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.

Comment 10 Laszlo Ersek 2018-06-11 17:29:25 UTC

Hi FuXiangChun, the testing looks sufficient to me. Thanks.

Comment 12 errata-xmlrpc 2018-10-30 09:36:07 UTC

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

Note You need to log in before you can comment on or make changes to this bug.