From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web10.8644.1668767539927021180 for ; Fri, 18 Nov 2022 02:32:20 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: pierre.gondois@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 46A4F23A; Fri, 18 Nov 2022 02:32:25 -0800 (PST) Received: from [10.34.100.128] (pierre123.nice.arm.com [10.34.100.128]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B4B9F3F663; Fri, 18 Nov 2022 02:32:17 -0800 (PST) Message-ID: Date: Fri, 18 Nov 2022 11:32:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg/RngDxe: Fix Rng algo selection for Arm To: Ard Biesheuvel , Sami Mujawar Cc: "devel@edk2.groups.io" , Ard Biesheuvel , Liming Gao , Jiewen Yao , Jian J Wang , nd References: <20221116150149.2200368-1-Pierre.Gondois@arm.com> From: "PierreGondois" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/18/22 11:14, Ard Biesheuvel wrote: > On Fri, 18 Nov 2022 at 11:10, Sami Mujawar wrote= : >> >> Hi Ard, >> >> Please find my response inline marked [SAMI]. >> >> Regards, >> >> Sami Mujawar >> >> =EF=BB=BFOn 18/11/2022, 09:56, "Ard Biesheuvel" wrot= e: >> >> On Wed, 16 Nov 2022 at 16:02, PierreGondois wrote: >> > >> > From: Pierre Gondois >> > >> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3D4151 >> > >> > 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 Rng= Lib, >> > the only Guid available for EFI_RNG_PROTOCOL will be the zero G= uid. >> > >> > 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 G= uids >> > should not be skipped (a.). >> > If no algorithm is found, don't prevent from booting on DEBUG b= uilds >> > (b.). >> > >> > Allow Zero Guids to be selected and don't ASSERT if no algorith= m is >> > found. Also simplify the selection of the Rng algorithm when th= e >> > default one is selected by just picking up the first element of >> > mAvailableAlgoArray. >> > >> > Reported-by: Sami Mujawar >> > Signed-off-by: Pierre Gondois >> >> I am still confused by this. >> >> Does this mean we might register the RNG protocol if we don't hav= e >> anything to back it up? >> [SAMI] From a Guest firmware implementation perspective, we do not kno= w 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 implement= ed on the host platform. If none of these are present, we would want to f= all back to VIRTIO RNG. >> >> Considering this, I think we should not register the EFI_RNG_PRTOCOL i= f no supported algorithms are present. >> >> The other argument would be that the protocol allows discovery of supp= orted RNG source. But looking how this is consumed in Linux, I think it i= s better to not register EFI_RNG_PRTOCOL if no supported algorithms are p= resent. >> >> Please do let me know your thoughts. >=20 > 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. >=20 > This means that checking for the existence of the EFI_RNG_PROTOCOL > should be sufficient to decide whether or not install another one. Hello, There would maybe be a case where the consumer explicitly requests the gEfiRngAlgorithmRaw GUID and the RngDxe doesn't detect it. So there would= be two EFI_RNG_PRTOCOL registered on different handles with different algorithms available. I am not sure of what should happen then. But about the inital point, EFI_RNG_PRTOCOL should indeed not be register= ed if no algorithm is available. Regards, Pierre