Hello! Marius Bakke <mba...@fastmail.com> skribis:
> Ludovic Courtès <l...@gnu.org> writes: [...] >> Bah, too bad, though it still doesn’t sound right to consume this much >> entropy right from the start. I’m surprised it doesn’t make any >> difference when you remove that bit. > > I guess generating 512 random bytes does not cost a lot of entropy. > Writing that made me curious, so I tested it: > > $ cat /proc/sys/kernel/random/entropy_avail > 3938 > $ head -c 512 /dev/urandom > /dev/null && !! > 3947 > > Wait, what? Trying again... > > $ head -c 512 /dev/urandom > /dev/null && cat > /proc/sys/kernel/random/entropy_avail > 3693 > [...typing this section of the email...] > $ head -c 512 /dev/urandom > /dev/null && cat > /proc/sys/kernel/random/entropy_avail > 3898 Uh! But that’s once the system is running, and with a long-enough pause in between reads… maybe? >> Perhaps we should print the value of /proc/…/entropy_avail in several >> places during boot time to get a better understanding. > > That could be useful. My understanding is that we were waiting for the > kernel to be absolutely certain that the entropy pool is sufficiently > random, i.e. "state 2" from this overview: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33 > > Once it is initialized, we get an "endless" stream of good random data > thanks to the entropy pool and ChaCha20(?). > > See also this article for an overview of the discussions that lead to > Torvalds' patch: > > https://lwn.net/SubscriberLink/800509/de787577364be340/ Interesting, thanks for the link! > Anyway, I pushed the upstream fix in > dd6989711370c43676edc974f86c8586f21f80f6. Coolio, now merging is no longer blocked due to entropy starvation! :-) Ludo’.