From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.8408.1668766466302187184 for ; Fri, 18 Nov 2022 02:14:26 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=J7p7HyJo; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5BD2362409 for ; Fri, 18 Nov 2022 10:14:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2ACF6C433D6 for ; Fri, 18 Nov 2022 10:14:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668766465; bh=5GOOnRZ2QoiOC8pdfUm1XbT9QbB+iws9jewOjKjX4Ig=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=J7p7HyJoW21XW8aUC03EaZVsm1ZpjwMyHbDx3qKTt8+rZ3dMWf8uhRfrBophqiFA5 n94vSAsnIqHQybS+ET8CpmvM2M5DhRAu0asDiwCXyN/JS4BW0ibWZ7Kj530/ak3nwl vmxODi0A1g98ETdzAGHRyRTo//2GaFsCp6qSn8p3mv2Mvg3hf2H0IBHJWWRbxzgYDb LUmoW/EmbtdS1SthRCVhsE2udjt7cKNmS0IWESkFmz2cdb8W7xyTr4uiY10aW32DTG TLT9NQ4A3YvWmyJvwex9CDM7nGpLh+0z6DCZQPHtuSG4tW48P3EuMFSrxAjZTOUXxm 8LagaHC8n8OLA== Received: by mail-lj1-f182.google.com with SMTP id u2so6201094ljl.3 for ; Fri, 18 Nov 2022 02:14:25 -0800 (PST) X-Gm-Message-State: ANoB5pnBFefY/oHlGEkap2C4neuR30HCC6RYy0jYgq3uNShfJDsc699r 1d1MZ+cfrLPZtfcI/Py5lv+aEvfCe05cY1DLsjQ= X-Google-Smtp-Source: AA0mqf43VxxqY83zYueNb1g6oE5oxZpRUyoqemfM8SNjWkEX4wvsadLvBZC3Nuls9uLMKGhETo0qlkiz2xtrpB7d9R4= X-Received: by 2002:a05:651c:220a:b0:277:2428:3682 with SMTP id y10-20020a05651c220a00b0027724283682mr2428757ljq.291.1668766463184; Fri, 18 Nov 2022 02:14:23 -0800 (PST) MIME-Version: 1.0 References: <20221116150149.2200368-1-Pierre.Gondois@arm.com> In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 18 Nov 2022 11:14:11 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg/RngDxe: Fix Rng algo selection for Arm To: Sami Mujawar Cc: "devel@edk2.groups.io" , Pierre Gondois , Ard Biesheuvel , Liming Gao , Jiewen Yao , Jian J Wang , nd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" wrote: > > 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 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 build= s > > (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 > > Signed-off-by: Pierre Gondois > > 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 t= he 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 b= ack to VIRTIO RNG. > > Considering this, I think we should not register the EFI_RNG_PRTOCOL if n= o supported algorithms are present. > > The other argument would be that the protocol allows discovery of support= ed RNG source. But looking how this is consumed in Linux, I think it is bet= ter 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.