(cc some ARM folks) On Mon, 13 May 2024 at 11:23, Gerd Hoffmann <kra...@redhat.com> wrote: > > On Sat, May 11, 2024 at 10:40:23AM GMT, Ard Biesheuvel wrote: > > As I pointed out before, on the ARM side there are a few intersecting > > issues with these changes. (On x86, this is mostly avoided due to the > > fact that RDRAND is universally supported) > > Well, it's not that easy on x86 either. > > Current state of affairs is that the time based LibRng is used, all > OvmfPkg / ArmVirtPkg have this: > > RngLib|MdeModulePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf > > So, this is what will be used if something uses LibRng. > > On x64 RngDxe will just use call LibRng too. So adding RngDxe will > effectively make BaseRngLibTimerLib available via EFI_RNG_PROTOCOL. > > In case '-device virtio-rng-pci' is present we now have *two* drivers > providing EFI_RNG_PROTOCOL. What will happen in this case? What we > surely not want is RngDxe being used in case we have a virtio-rng > device ... >
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 The ARM version of RngLib can be backed by either RNDR or TRNG, and exposes gEfiRngAlgorithmArmRndr, gEfiRngAlgorithmRaw, or both. If neither are supported, RngDxe will not be dispatched. Given that RNDR is implemented by the hardware, and TRNG by the hypervisor, and neither depend on the UEFI driver model (like virtio-rng), which is backed by the VMM, I think that in this case, there is no issue with dispatching both, even if that results in two implementations of the EFI_RNG_PROTOCOL, and no guarantees regarding which one you get when you locate the protocol. (Confidential VMs may want to avoid virtio-rng as it is provided by the host but let's disregard that for the time being) The upshot is that existing ARM deployments that do not use the 'max' CPU in TCG mode, or are on a fairly old version of KVM will lose network support unless they enable the virtio-rng-pci device. This is a situation I can live with, but it does require the changes I am proposing on the branch above. On x86, we should avoid BaseRngLibTimerLib as well - it is a bit ugly to expose two EFI_RNG_PROTOCOL instances, but we could at least ensure that it doesn't matter which one you grab. I intend to look more deeply into this in the future, and maybe compare notes with Pierre, as this has been a rather complicated delivery IIRC. Perhaps it would be better for RngDxe to consume a raw entropy source and implement the DRBG directly rather than expose the raw protocol (which I think should not have been introduced in the first place) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118872): https://edk2.groups.io/g/devel/message/118872 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] -=-=-=-=-=-=-=-=-=-=-=-
