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.
