aboutsummaryrefslogtreecommitdiff
path: root/include/linux/fpga/fpga-mgr.h
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2021-12-29 22:10:05 +0100
committerJason A. Donenfeld <Jason@zx2c4.com>2022-01-07 00:25:25 +0100
commit73c7733f122e8d0107f88655a12011f68f69e74b (patch)
treebc6beb31cbd53e3e157d6fae0b7cfb5526d258e9 /include/linux/fpga/fpga-mgr.h
parent9c3ddde3f811aabbb83778a2a615bf141b4909ef (diff)
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>
Diffstat (limited to 'include/linux/fpga/fpga-mgr.h')
0 files changed, 0 insertions, 0 deletions