Re: [PATCH] random: allow writes to /dev/urandom to influence fast init

["Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>]

Excerpts from Jason A. Donenfeld's message of March 23, 2022 11:18 pm:
> Hi all,
> 
> [...]
>
> In light of that conclusion, I'm going to work with every userspace
> downstream I can find to help them fix their file-based seeding, if it
> has bugs. I've started talking with the buildroot folks, and then I'll
> speak with the OpenRC people (being a Gentoo dev, that should be easy
> going). Systemd does the right thing already.
> 
> I wrote a little utility for potential inclusion in
> busybox/util-linux/whatever when it matures beyond its current age of
> being half hour old:
> - https://git.zx2c4.com/seedrng/about/
> - https://git.zx2c4.com/seedrng/tree/seedrng.c
> So I'll see what the buildroot people think of this and take it from there.
> 
> The plus side of doing all this is that, if the efforts pan out, it
> means there'll actually be proper seeding on devices that don't
> currently do that, which then might lead to a better ecosystem and
> less boot time blocking and all that jazz.
> 
> Jason
> 

The issue, in systemd developers' opinion, is that counting seed file 
towards entropy initialization potentially causes repeated RNG output if 
a system is cloned without resetting the seed file. This is discussed at 
length in https://github.com/systemd/systemd/pull/4513. A few years ago, 
I wrote most of a program to check machine ID, disk ID, DMI ID, and some 
other things in order to avoid this issue. Since then, systemd decided 
to store the random seed in EFI variables, I assume on the basis that 
machine cloning typically does not clone the EFI variables? In my 
opinion, since the same argument applies to machine ID, ssh keys, and 
any other persistent cryptographic (or even non-cryptographic) material, 
this falls outside the scope of random seeding and into a general 
machine cloning "sysprep"-like utility.

Cheers,
Alex.