[This is very much an early Request For Comments - it builds and shows a sketch of what I have in mind, but has not really been tested. The rest of the cover letter is copied from patch 3.]
A recurring theme on LKML is the boot process deadlocking due to some process blocking waiting for random numbers, while the kernel's Cryptographic Random Number Generator (crng) is not initalized yet, but that very blocking means no activity happens that would generate the entropy necessary to finalize seeding the crng.
This is not a problem on boards that have a good hwrng (when the kernel is configured to trust it), whether in the CPU or in a TPM or elsewhere. However, that's far from all boards out there.
Moreover, when booting with an initrd, all the "disk activity" that would otherwise generate some timing variances has already been done by U-boot. Hence it makes sense to try to collect that entropy in U-boot and pass it on to the kernel. On the kernel side, support for that has just landed in master (commit 428826f5358c "fdt: add support for rng-seed").
By itself, this does not help with the initialization of the crng, since the kernel only considers the rng-seed "trustworthy" if CONFIG_RANDOM_TRUST_BOOTLOADER is set (it is always fed into the crng, but entropy is only accounted when that config option is set).
This adds some basic infrastructure for collecting entropy in U-boot, and then it's up to the BSP developer to decide if CONFIG_RANDOM_TRUST_BOOTLOADER should be enabled in the kernel.
If this is accepted, I think we should add entropy() calls before and after most disk and network activities. Moreover, at least some boards seem to have a rather reliable source of randomness in the contents of RAM after a cold boot [*], so I imagine exposing the entropy_mix() either via a command "entropy <addr> <len>" that can be run during a boot script, or perhaps to be done automatically (and as early as possible to reduce risk of "tainting") via some CONFIG_ENTROPY_RAM_{ADDR,LEN}.
There's probably good sources of entropy to be had from the SPL phase, but I couldn't find a good way of passing that on other than by putting the sha256_context inside global_data, which would bloat that by over 100 bytes.
[*] Looking at a slightly arbitrary place in the middle of physical memory I got these
40d07670: 34081000 400a8020 00002040 20024400 ...4 ..@@ ...D. 40d07670: 343c1000 640a9120 00036040 6006e400 ..<4 ..d@`.....` 40d07670: 353c1040 600a9120 00026041 6246e400 @.<5 ..`A`....Fb 40d07670: 34281000 600a9100 00026040 2046e400 ..(4...`@`....F
So some bits are always the same, but there's quite a few that flip randomly between boots - so mixing in a MB or two seems that it should provide plenty of real entropy.
Rasmus Villemoes (3): u-boot/sha256.h: add SHA256_INIT macro u-boot/sha256.h: include linux/types.h add infrastructure for collecting entropy
common/fdt_support.c | 12 ++++++++ include/common.h | 3 ++ include/entropy.h | 42 +++++++++++++++++++++++++++ include/u-boot/sha256.h | 13 +++++++++ lib/Kconfig | 10 +++++++ lib/Makefile | 1 + lib/entropy.c | 63 +++++++++++++++++++++++++++++++++++++++++ 7 files changed, 144 insertions(+) create mode 100644 include/entropy.h create mode 100644 lib/entropy.c