aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/scripts/gdb/linux/utils.py
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 /scripts/gdb/linux/utils.py
parentrandom: do not re-init if crng_reseed completes before primary init (diff)
downloadwireguard-linux-73c7733f122e8d0107f88655a12011f68f69e74b.tar.xz
wireguard-linux-73c7733f122e8d0107f88655a12011f68f69e74b.zip
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 'scripts/gdb/linux/utils.py')
0 files changed, 0 insertions, 0 deletions