Currently, we only expose EFI_RNG_PROTOCOL when running under QEMU if it
exposes a virtio-rng device. This means that generic EFI apps or
loaders have no access to an entropy source if this device is
unavailable, unless they implement their own arch-specific handling to
figure out whether any CPU instructions or monitor calls can be used
instead.
So let's wire those up as EFI_RNG_PROTOCOL implementations as well,
using the existing drivers and libraries.
First patch is a bugfix - Liming, mind if I merge that right away?
Thanks.
Cc: Liming Gao <gaolim...@byosoft.com.cn>
Cc: Rebecca Cran <rebe...@bsdio.com>
Cc: Pierre Gondois <pierre.gond...@arm.com>
Cc: Leif Lindholm <quic_llind...@quicinc.com>
Cc: Sami Mujawar <sami.muja...@arm.com>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: Jason A. Donenfeld <ja...@zx2c4.com>
Ard Biesheuvel (3):
ArmPkg/ArmTrngLib: Fix incorrect GUID reference in DEBUG() output
ArmVirtPkg/ArmVirtQemu: Expose TRNG hypercall via RngDxe if
implemented
OvmfPkg/OvmfX86: Enable RDRAND based EFI_RNG_PROTOCOL implementation
ArmPkg/Library/ArmTrngLib/ArmTrngLib.c | 2 +-
ArmVirtPkg/ArmVirtQemu.dsc | 11 +++++++++++
ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 5 +++++
ArmVirtPkg/ArmVirtQemuKernel.dsc | 11 +++++++++++
OvmfPkg/OvmfPkgIa32.dsc | 1 +
OvmfPkg/OvmfPkgIa32.fdf | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
OvmfPkg/OvmfPkgX64.dsc | 1 +
OvmfPkg/OvmfPkgX64.fdf | 1 +
10 files changed, 34 insertions(+), 1 deletion(-)
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96188): https://edk2.groups.io/g/devel/message/96188
Mute This Topic: https://groups.io/mt/94935839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
