On Fri, May 17, 2024 at 09:27:53AM GMT, Ard Biesheuvel wrote: > On Fri, 17 May 2024 at 05:27, Doug Flick via groups.io > <dougflick=microsoft....@groups.io> wrote: > > > > On ARM, we can actually do better than this: I have taken Doug's v2 and > > applied some changes on top to make it work with ArmVirtQemu. > > > > https://github.com/ardbiesheuvel/edk2/tree/doug-v2 > > > > Ard, would you be comfortable with this patch series if I take the commits > > you're suggesting? I'm being asked to see what it would take to get these > > commits in for this release. > > I won't object to that, but I'd like Gerd's take as well, given that a > similar concern appears to apply to OVMF/x86 IIUC.
I think including RngDxe in OvmfPkg is not an option. That would be a silent regression on the random number quality delivered by EFI_RNG_PROTOCOL because OvmfPkg uses BaseRngLibTimerLib. Switching to BaseRngLib is an easy way out for physical platforms with a sufficient recent processor. OVMF can not assume the rdrand instruction is available, so that is not possible. So short-term (i.e. 2024-05 stable tag) the only option I see is depending on virtio-rng. Which is a regression too (network booting without '-device virtio-rng-pci' breaks), but it is an obvious failure with an easy fix. Not an ideal solution, but much better than a regression which can easily go unnoticed. Longer term it probably makes sense to have a EFI_RNG_PROTOCOL driver using the rdrand instruction and runtime detection whenever the instruction is available or not. Either by adapting RngDxe accordingly, or by having an OVMF-specific driver handling the runtime detection. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119016): https://edk2.groups.io/g/devel/message/119016 Mute This Topic: https://groups.io/mt/106013302/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
