On Fri, 18 Nov 2022 at 11:10, Sami Mujawar <sami.muja...@arm.com> wrote: > > Hi Ard, > > Please find my response inline marked [SAMI]. > > Regards, > > Sami Mujawar > > On 18/11/2022, 09:56, "Ard Biesheuvel" <a...@kernel.org> wrote: > > On Wed, 16 Nov 2022 at 16:02, PierreGondois <pierre.gond...@arm.com> > wrote: > > > > From: Pierre Gondois <pierre.gond...@arm.com> > > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4151 > > > > The EFI_RNG_PROTOCOL can advertise multiple algorithms through > > Guids. The PcdCpuRngSupportedAlgorithm contains a Guid that > > can be configured. It represents the algorithm used in RngLib. > > PcdCpuRngSupportedAlgorithm is set to the Zero Guid for KvmTool. > > > > When running KvmTool on a platform platform only having the RngLib, > > the only Guid available for EFI_RNG_PROTOCOL will be the zero Guid. > > > > To select the default algorithm in EFI_RNG_PROTOCOL.GetRng(): > > a. Zero Guids are skipped > > b. If no algorithm is found, an ASSERT is triggered > > > > To allow using the RngLib to be used for the case above, Zero Guids > > should not be skipped (a.). > > If no algorithm is found, don't prevent from booting on DEBUG builds > > (b.). > > > > Allow Zero Guids to be selected and don't ASSERT if no algorithm is > > found. Also simplify the selection of the Rng algorithm when the > > default one is selected by just picking up the first element of > > mAvailableAlgoArray. > > > > Reported-by: Sami Mujawar <sami.muja...@arm.com> > > Signed-off-by: Pierre Gondois <pierre.gond...@arm.com> > > I am still confused by this. > > Does this mean we might register the RNG protocol if we don't have > anything to back it up? > [SAMI] From a Guest firmware implementation perspective, we do not know the > available RNG source. > It may be CPU RNG, Arm FW TRNG or VIRTIO RNG. > I would assume either one of CPU RNG or Arm FW TRNG would be implemented on > the host platform. If none of these are present, we would want to fall back > to VIRTIO RNG. > > Considering this, I think we should not register the EFI_RNG_PRTOCOL if no > supported algorithms are present. > > The other argument would be that the protocol allows discovery of supported > RNG source. But looking how this is consumed in Linux, I think it is better > to not register EFI_RNG_PRTOCOL if no supported algorithms are present. > > Please do let me know your thoughts.
Agreed. I am adding support for the TRNG to the QEMU firmware, and if this is supported, there is really no point in attaching a driver to virtio-rng as well. This means that checking for the existence of the EFI_RNG_PROTOCOL should be sufficient to decide whether or not install another one. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#96493): https://edk2.groups.io/g/devel/message/96493 Mute This Topic: https://groups.io/mt/95067856/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
