random: do not throw away excess input to crng_fast_load
authorJason A. Donenfeld <Jason@zx2c4.com>
Wed, 29 Dec 2021 21:10:05 +0000 (22:10 +0100)
committerJason A. Donenfeld <Jason@zx2c4.com>
Thu, 6 Jan 2022 23:25:25 +0000 (00:25 +0100)
commit73c7733f122e8d0107f88655a12011f68f69e74b
treebc6beb31cbd53e3e157d6fae0b7cfb5526d258e9
parent9c3ddde3f811aabbb83778a2a615bf141b4909ef
random: do not throw away excess input to crng_fast_load

When crng_fast_load() is called by add_hwgenerator_randomness(), we
currently will advance to crng_init==1 once we've acquired 64 bytes, and
then throw away the rest of the buffer. Usually, that is not a problem:
When add_hwgenerator_randomness() gets called via EFI or DT during
setup_arch(), there won't be any IRQ randomness. Therefore, the 64 bytes
passed by EFI exactly matches what is needed to advance to crng_init==1.
Usually, DT seems to pass 64 bytes as well -- with one notable exception
being kexec, which hands over 128 bytes of entropy to the kexec'd kernel.
In that case, we'll advance to crng_init==1 once 64 of those bytes are
consumed by crng_fast_load(), but won't continue onward feeding in bytes
to progress to crng_init==2. This commit fixes the issue by feeding
any leftover bytes into the next phase in add_hwgenerator_randomness().

[linux@dominikbrodowski.net: rewrite commit message]
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
drivers/char/random.c