summaryrefslogtreecommitdiff
path: root/arch/parisc
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2021-12-29 22:10:05 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-01-27 09:19:46 +0100
commit5e126f68808ca1aa557b87a1695f1efcefecd78b (patch)
tree637c79c15e5d9a36125f07f34be5c78736e10820 /arch/parisc
parent8f6cecfff36ccd6a19fec2f6403abc3dcd870f8e (diff)
random: do not throw away excess input to crng_fast_load
[ Upstream commit 73c7733f122e8d0107f88655a12011f68f69e74b ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'arch/parisc')
0 files changed, 0 insertions, 0 deletions