aboutsummaryrefslogtreecommitdiff
path: root/scripts/bpf_doc.py
diff options
context:
space:
mode:
authorJason A. Donenfeld <[email protected]>2021-12-29 22:10:05 +0100
committerJason A. Donenfeld <[email protected]>2022-01-07 00:25:25 +0100
commit73c7733f122e8d0107f88655a12011f68f69e74b (patch)
treebc6beb31cbd53e3e157d6fae0b7cfb5526d258e9 /scripts/bpf_doc.py
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(). [[email protected]: rewrite commit message] Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
Diffstat (limited to 'scripts/bpf_doc.py')
0 files changed, 0 insertions, 0 deletions