Messages in this thread | | | Date | Tue, 22 Mar 2022 12:19:16 -0600 | From | "Jason A. Donenfeld" <> | Subject | Re: [PATCH v1] random: block in /dev/urandom |
| |
Hi Guenter,
On Tue, Mar 22, 2022 at 10:56:44AM -0700, Guenter Roeck wrote: > Everything - including the various root file systems - is at > git@github.com:groeck/linux-build-test.git. Look into rootfs/ for the > various boot tests. I'll be happy to provide some qemu command lines > if needed.
Thanks. It looks like the "problem" is with this shell script:
init_rng() { if check_file_size; then printf 'Initializing random number generator: ' dd if="$URANDOM_SEED" bs="$pool_size" of=/dev/urandom count=1 2> /dev/null status=$? if [ "$status" -eq 0 ]; then echo "OK" else echo "FAIL" fi return "$status" fi } save_random_seed() { printf 'Saving random seed: ' if touch "$URANDOM_SEED" 2> /dev/null; then old_umask=$(umask) umask 077 dd if=/dev/urandom of="$URANDOM_SEED" bs="$pool_size" count=1 2> /dev/null status=$? umask "$old_umask" if [ "$status" -eq 0 ]; then echo "OK" else echo "FAIL" fi else status=$? echo "SKIP (read-only file system detected)" fi return "$status" }
case "$1" in start|restart|reload) # Carry a random seed from start-up to start-up # Load and then save the whole entropy pool init_rng && save_random_seed;;
This code is actually problematic for a number of reasons. (And Linus, I'm not saying "userspace is wrong" to justify breaking it or something, don't worry.)
The first `dd if="$URANDOM_SEED" bs="$pool_size" of=/dev/urandom count=1` will write the seed into the input pool, but:
- It won't credit the entropy from that seed, so the pool won't actually initialize. (You need to use the ioctl to credit it.) - Because the pool doesn't initialize, subsequent reads from /dev/urandom won't actually use that seed.
The first point is why we had to revert this patch. But the second one is actually a bit dangerous: you might write in a perfectly good seed to /dev/urandom, but what you read out for the subsequent seed may be complete deterministic crap. This is because the call to write_pool() goes right into the input pool and doesn't touch any of the "fast init" stuff, where we immediately mutate the crng key during early boot.
As far as I can tell, this has been the behavior for a really long time, making the above innocuous pattern a pretty old thing that's broken. So I could perhaps say, "this behavior is so old now, that your userspace code is just plain broken," but I think I might actually have a very quick unobtrusive fix for this. I'll mull some things over for rc2 or later in rc1.
But, anyway, this only fixes the second point mentioned above. The first one -- which resulted in the revert -- remains a stumper for now.
Jason
| |