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
next prev parent 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