| Message ID | 20221116161642.1670235-1-Jason@zx2c4.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Use EFI variables for random seed | expand |
On Mi, 16.11.22 17:16, Jason A. Donenfeld (Jason@zx2c4.com) wrote: > Commit messages are rather sparse at the moment. I'll fill those out for > the next non-RFC patchset if this idea isn't immediately demolished. > > The biggest consideration is wear leveling on the EFI variable flash > chips. However, EFI *already* winds up writing to non-volatile memory on > every single boot anyway, so maybe it's not actually a big deal? So as mentioned elsewhere: This might (probably more than) double the wear on the flash chips, since firmware is unlikely to batch these writes with the monotonic counter write. I have no idea how realistic these issues are, there's a lot of handwaving involved, but to sidestep the issue I put sd-boot's seed in a file on disk (which should not have issues that much with wear) instead of efi vars. Lennart
On Wed, Nov 16, 2022 at 6:59 PM Lennart Poettering <lennart@poettering.net> wrote: > > On Mi, 16.11.22 17:16, Jason A. Donenfeld (Jason@zx2c4.com) wrote: > > > Commit messages are rather sparse at the moment. I'll fill those out for > > the next non-RFC patchset if this idea isn't immediately demolished. > > > > The biggest consideration is wear leveling on the EFI variable flash > > chips. However, EFI *already* winds up writing to non-volatile memory on > > every single boot anyway, so maybe it's not actually a big deal? > > So as mentioned elsewhere: This might (probably more than) double the > wear on the flash chips, since firmware is unlikely to batch these > writes with the monotonic counter write. > > I have no idea how realistic these issues are, there's a lot of > handwaving involved, but to sidestep the issue I put sd-boot's seed in > a file on disk (which should not have issues that much with wear) > instead of efi vars. Therein lies the rub indeed. Does anybody who knows something about the hardware and historical hardware know for certain that this would be a bad idea, or does it really not matter at all? Would be useful to have some definitive advice here. Jason
This is a rough sketch of a proposal to use non-volatile EFI variables as random seeds for EFISTUB to manage. Patch 1 adds (back) the random.c async notifier, so we can learn when the RNG is initialized. Patch 2 uses it in vsprintf, because I promised Sebastian we'd do that if it ever gets added back for whatever reason. Patch 3 is already in efi.git and isn't new here, but is a pre-req for the next patch. Patch 4 uses the random seed from an EFI variable to pass to Linux. Patch 5 prevents the variable from being read by efivarfs. [Note: probably the legacy efifs needs updating too? Or has this been removed?] Patch 6 uses patch 1 to refresh the EFI variable when the RNG is initialized. If folks like this idea and it moves forward, 1,2,6 will be taken into my tree, and 3,4,5 will go via Ard's. Commit messages are rather sparse at the moment. I'll fill those out for the next non-RFC patchset if this idea isn't immediately demolished. The biggest consideration is wear leveling on the EFI variable flash chips. However, EFI *already* winds up writing to non-volatile memory on every single boot anyway, so maybe it's not actually a big deal? Thoughts? Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Lennart Poettering <lennart@poettering.net> Ard Biesheuvel (1): efi: random: combine bootloader provided RNG seed with RNG protocol output Jason A. Donenfeld (5): random: add back async readiness notifier vsprintf: initialize siphash key using notifier efi: stub: use random seed from EFI variable efi: efivarfs: prohibit reading random seed variables efi: refresh non-volatile random seed when RNG is initialized drivers/char/random.c | 30 +++++++++ drivers/firmware/efi/efi.c | 14 +++++ drivers/firmware/efi/libstub/efistub.h | 2 + drivers/firmware/efi/libstub/random.c | 85 +++++++++++++++++++++++--- fs/efivarfs/file.c | 3 + include/linux/efi.h | 3 +- include/linux/random.h | 1 + lib/vsprintf.c | 14 ++--- 8 files changed, 131 insertions(+), 21 deletions(-)