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.web09.7630.1668088080789500980
 for <devel@edk2.groups.io>;
 Thu, 10 Nov 2022 05:48:00 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@kernel.org header.s=k20201202 header.b=glfXtjLP;
 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 2FB276163C;
	Thu, 10 Nov 2022 13:48:00 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A41FCC433D6;
	Thu, 10 Nov 2022 13:47:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1668088079;
	bh=rZgERiH/Jvv4A15+03CgZkATUgAiw5hB5ClyWz8rOwY=;
	h=From:To:Cc:Subject:Date:From;
	b=glfXtjLPQU6dT966aAejMRUjzzvjqTuiLzx2rDvfCfRZIbKDImAWP/FPVZyWq1rzP
	 Ggn1hklzIqtwRDaXzeHaThpqcb2ZJNd/HMAdw9zV/TyvXsjHcTRrWaukxXy9Og9d9J
	 5QzvB/gG3qiVvKx/4szxqWlaz0h/nxH10eJUM+VyOe9v/D6Usz5Xa9R/1Vb98Hqylh
	 4TVa8StrrAphCtfrpmwmSFl3ZKvOVUCdDOnOv2uYAiJnsTM8lfc1i+1PLVaApAHRtJ
	 U4woGpkpmeM71jMCccoJXM8xSZWqdXRYy5Lefvca12SzXtdtnqRq7ltVCo9HphN/dA
	 p/NpcsDDHXI3A==
From: "Ard Biesheuvel" <ardb@kernel.org>
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Liming Gao <gaoliming@byosoft.com.cn>,
	Rebecca Cran <rebecca@bsdio.com>,
	Pierre Gondois <pierre.gondois@arm.com>,
	Leif Lindholm <quic_llindhol@quicinc.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"Jason A . Donenfeld" <Jason@zx2c4.com>
Subject: [PATCH 0/3] OVMF: support EFI_RNG_PROTOCOL without virtio-rng
Date: Thu, 10 Nov 2022 14:47:35 +0100
Message-Id: <20221110134738.3798618-1-ardb@kernel.org>
X-Mailer: git-send-email 2.35.1
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Currently, we only expose EFI_RNG_PROTOCOL when running under QEMU if it=0D
exposes a virtio-rng device. This means that generic EFI apps or=0D
loaders have no access to an entropy source if this device is=0D
unavailable, unless they implement their own arch-specific handling to=0D
figure out whether any CPU instructions or monitor calls can be used=0D
instead.=0D
=0D
So let's wire those up as EFI_RNG_PROTOCOL implementations as well,=0D
using the existing drivers and libraries.=0D
=0D
First patch is a bugfix - Liming, mind if I merge that right away?=0D
Thanks.=0D
=0D
Cc: Liming Gao <gaoliming@byosoft.com.cn>=0D
Cc: Rebecca Cran <rebecca@bsdio.com>=0D
Cc: Pierre Gondois <pierre.gondois@arm.com>=0D
Cc: Leif Lindholm <quic_llindhol@quicinc.com>=0D
Cc: Sami Mujawar <sami.mujawar@arm.com>=0D
Cc: Gerd Hoffmann <kraxel@redhat.com>=0D
Cc: Jason A. Donenfeld <Jason@zx2c4.com>=0D
=0D
Ard Biesheuvel (3):=0D
  ArmPkg/ArmTrngLib: Fix incorrect GUID reference in DEBUG() output=0D
  ArmVirtPkg/ArmVirtQemu: Expose TRNG hypercall via RngDxe if=0D
    implemented=0D
  OvmfPkg/OvmfX86: Enable RDRAND based EFI_RNG_PROTOCOL implementation=0D
=0D
 ArmPkg/Library/ArmTrngLib/ArmTrngLib.c |  2 +-=0D
 ArmVirtPkg/ArmVirtQemu.dsc             | 11 +++++++++++=0D
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc   |  5 +++++=0D
 ArmVirtPkg/ArmVirtQemuKernel.dsc       | 11 +++++++++++=0D
 OvmfPkg/OvmfPkgIa32.dsc                |  1 +=0D
 OvmfPkg/OvmfPkgIa32.fdf                |  1 +=0D
 OvmfPkg/OvmfPkgIa32X64.dsc             |  1 +=0D
 OvmfPkg/OvmfPkgIa32X64.fdf             |  1 +=0D
 OvmfPkg/OvmfPkgX64.dsc                 |  1 +=0D
 OvmfPkg/OvmfPkgX64.fdf                 |  1 +=0D
 10 files changed, 34 insertions(+), 1 deletion(-)=0D
=0D
-- =0D
2.35.1=0D
=0D