Linux EFI development
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org
Subject: Re: [PATCH] efi: random: wait for CRNG to become ready before refreshing the seed
Date: Thu, 9 Jun 2022 11:02:57 +0200	[thread overview]
Message-ID: <YqG3QRovkHQ0TJib@zx2c4.com> (raw)
In-Reply-To: <20220608153216.1480073-1-ardb@kernel.org>

Hi Ard,

I'm trying to break the analysis down a bit to figure out what should be
done here. Can you tell me if any of these points are incorrect?

Case 0) EFI fails to provide any randomness at all.
        Result: nothing happens on kexec; add_bootloader_randomness() is
	used by nobody.

Case 1) EFI provides randomness. Parent kernel is trust_bootloader=y.
        Child kernel is trust_bootloader=y.
	Result: parent makes new seed for child, and everything works fine.

Case 2) EFI provides randomness. Parent kernel is trust_bootloader=y.
        Child kernel is trust_bootloader=n.
	Result: parent makes new seed for child, which child doesn't
	credit, but everything still works fine.

Case 3) EFI provides randomness. Parent kernel is trust_bootloader=n.
        Child kernel is trust_bootloader=n.
	Result: parent makes new seed for child using a technically
	uninitialized RNG that is still of EFI-quality, which child
	doesn't credit, so everything still works fine.

Case 4) EFI provides randomness. Parent kernel is trust_bootloader=n.
        Child kernel is trust_bootloader=y.
	Result: parent makes new seed for child using a technically
	uninitialized RNG that is still of EFI-quality, which child then
	credits. On the surface, this seems bad. But actually, the
	randomness here is still at least as good as what EFI provided,
	which is what trust_bootloader=y means anyway. So I think this
	case is actually fine.

Since all cases are fine, I don't think this patch is actually needed.
The interesting thing about this exercise, though, is that the thing
that enables this conclusion is the base case 0, where we notice that
kexec doesn't pass a seed if EFI isn't passing any randomness in the
first place. Were that not so, then case 4 would be dangerous.

The question I have is whether the same holds for how device tree is
doing things. There, they check rng_is_initialized(), which means the
worst is avoided, I suppose, but doing so precludes the nice properties
that EFI has for cases 3 and 4. Is there a way to do things better
there, or not really?

Jason

  reply	other threads:[~2022-06-09  9:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08 15:32 [PATCH] efi: random: wait for CRNG to become ready before refreshing the seed Ard Biesheuvel
2022-06-09  9:02 ` Jason A. Donenfeld [this message]
2022-06-09  9:39   ` Ard Biesheuvel

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-all 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=YqG3QRovkHQ0TJib@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=linux-efi@vger.kernel.org \
    /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