public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Pedro Falcato <pedro.falcato@gmail.com>
Cc: devel@edk2.groups.io, 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>
Subject: Re: [edk2-devel] [PATCH 3/3] OvmfPkg/OvmfX86: Enable RDRAND based EFI_RNG_PROTOCOL implementation
Date: Tue, 22 Nov 2022 13:20:16 +0100	[thread overview]
Message-ID: <Y3y+gBRkohmahc3G@zx2c4.com> (raw)
In-Reply-To: <CAKbZUD30=NA-7uD-qQvLC0r4cYrDJStsB47q_MyLf75kh67cKw@mail.gmail.com>

Hi Pedro,

On Tue, Nov 22, 2022 at 12:35 PM Pedro Falcato <pedro.falcato@gmail.com> wrote:
> Given this patch plus the corresponding linux-efi patches wrt RNG, I'm
> mildly concerned about buggy RDRAND implementations compromising the
> kernel's RNG. Is this not a concern?

Speaking with my kernel RNG maintainer hat on, no, this is not really a
concern, for several reasons:

- The kernel's RNG takes input from multiple sources, continuously, and
  tries to mix in new inputs rather quickly, especially at early boot.

- The kernel will use RDRAND on its own, even in the case that EFI
  doesn't provide it, so it's not gaining anything here.

- EFI on actual baremetal firmware, as opposed to OVMF, already provides
  EFI, so this is par for the course.

- Most of those RDRAND bugs have concerned coming in and out of various
  sleep states, which doesn't really apply to early boot EFI.

- And again, just to reinforce the first point, the kernel takes inputs
  from many sources. Having EFI provide its own thing -- via RDRAND or
  any other mechanism -- is complementary and will only help.

Regarding your "corresponding linux-efi patches wrt RNG", I'm not quite
sure what you're referring to. If anything, recent work during this
cycle has been aimed around shuffling more sources of randomness in from
elsewhere. The EFI RNG protocol stuff has been in there already for a
long time. So maybe you misunderstood those? Or I'm misunderstanding
what you're referring to?

As a general point, this question of "do we have enough entropy?" or
"are we initialized yet?" is an impossible proposition. Entropy
estimation is impossible, and is only ever a guess, and that guess can
be sometimes wrong, even wildly wrong. So the kernel is increasingly
moving away from /relying/ on that, and is more focused on getting more
sources faster -- incorporating anything it can find, and mixing it into
the output stream more continuously. To that end, if EFI's got a DXE to
do something or another, please hook it up.

Lastly, I think the concern you raised is inappropriate for Ard's
patchset, as it actually doesn't apply to it at all. This patchset is
about hooking an existing DXE up to OVMF, one that is hooked up
elsewhere, but wasn't for OVMF. This alone has nothing to do with the
concern. Rather, the concerns you raised are about the DXE itself. So to
that end, perhaps you should start a new thread or send some patches or
do something to the DXE that you're concerned about (e.g. a basic boring
power-on selftest like what the kernel has or something, if you're extra
worried). Or maybe not, for the reasons I listed above of things being
basically fine.

Jason

  reply	other threads:[~2022-11-22 12:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10 13:47 [PATCH 0/3] OVMF: support EFI_RNG_PROTOCOL without virtio-rng Ard Biesheuvel
2022-11-10 13:47 ` [PATCH 1/3] ArmPkg/ArmTrngLib: Fix incorrect GUID reference in DEBUG() output Ard Biesheuvel
2022-11-10 14:39   ` Sami Mujawar
2022-11-10 13:47 ` [PATCH 2/3] ArmVirtPkg/ArmVirtQemu: Expose TRNG hypercall via RngDxe if implemented Ard Biesheuvel
2022-11-18 16:48   ` PierreGondois
2023-01-11 16:49     ` [edk2-devel] " Ard Biesheuvel
2023-01-11 17:38       ` PierreGondois
2023-01-11 17:45         ` Ard Biesheuvel
2022-11-10 13:47 ` [PATCH 3/3] OvmfPkg/OvmfX86: Enable RDRAND based EFI_RNG_PROTOCOL implementation Ard Biesheuvel
2022-11-22 11:35   ` [edk2-devel] " Pedro Falcato
2022-11-22 12:20     ` Jason A. Donenfeld [this message]
2022-11-22 12:45       ` Pedro Falcato
2022-11-22 13:10         ` Jason A. Donenfeld
2022-11-22 14:17           ` Pedro Falcato
2022-11-22 14:21             ` Jason A. Donenfeld
2022-11-22 12:29     ` Jason A. Donenfeld
2022-11-11  0:41 ` 回复: [PATCH 0/3] OVMF: support EFI_RNG_PROTOCOL without virtio-rng gaoliming
2022-11-11  2:41 ` Jason A. Donenfeld
2022-11-11  7:47   ` Ard Biesheuvel
2022-11-11 17:03     ` Jason A. Donenfeld
     [not found] ` <172660F4A69E435E.25609@groups.io>
2022-11-11  3:53   ` 回复: [edk2-devel] 回复: " gaoliming
2022-11-11  7:34     ` Ard Biesheuvel
2022-11-11  8:14 ` [edk2-devel] " Gerd Hoffmann
2023-01-10 18:19 ` Jason A. Donenfeld
2023-01-11 11:41   ` Ard Biesheuvel
2023-01-11 15:23   ` [edk2-devel] " Laszlo Ersek
2023-01-11 16:03     ` Ard Biesheuvel
2023-01-11 16:05       ` Ard Biesheuvel
2023-01-12  9:27         ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3y+gBRkohmahc3G@zx2c4.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox