Don't try to improve Kernel randomness

[lategoodbye]

According Kernel developer Jason A. Donenfeld it's not the job of userspace to care of randomness:

"That script has always been wrong. Writing to /dev/urandom like that has never ensured that those bytes are taken into account immediately after. It's just not how that interface works. So any assumptions based on that are bogus, and that line effectively does nothing.

Fortunately, however, the kernel itself incorporates hwrng output into the rng pool, so you don't need to think about doing it yourself.

So go ahead and remove that line from your script."

Link: https://lore.kernel.org/linux-crypto/20e3c73c-7736-b010-516a-6618c88d8dad@gmx.net/T/#mfd7cca35fe18d6039fbcb2201317a38456cb5b67

[MichaIng]

Whether writing to /dev/urandom does "assure" that those bytes are taken into account or not, in practice it just works? The kernel itself does not incorporate hwrng output into the rng pool sufficiently, this is why random generator daemons like rng-tools/rngd or haveged exist, i.e. in fact userspace taking care of randomness with tools explicitly existing for this. Or has something chanced about this in recent Linux versions?

RPi OS ships with rng-tools pre-installed, so as long as this script runs after init, the line should be indeed not needed. But it is executed here: https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/8f1815e/usr/lib/raspberrypi-sys-mods/firstboot#L176 This script runs as replacement for init on first boot, hence no random generator daemon is running at this point, and hence it is pretty much possible that the true random pool is not sufficiently filled to generate all SSH host keys. /dev/urandom spits out pseudo randomness when the pool is empty, which is not great for cryptographic tasks like this. So if there is a chance to fill the true randomness pool beforehand, it does not make anything worse but has a chance to increase the quality of the generated keys.

But to be true, while I know the practice to manually feed /dev/random, I am not entirely sure whether it really works the same way with /dev/urandom. AFAIK, it might even work more reliable to feed /dev/random (the true randomness pool) and then take from /dev/urandom, as both use the same true randomness pool until it is empty?

[XECDesign]

This line has always felt a bit cargo-culty and I trust Stefan's and other upstream developers' judgement on this.

[MichaIng]

I suggest to at least test this once on a real RPi first boot, to see whether it now hangs on SSH hostkey generation. This would be the reason why the line was added in the first place.

[zx2c4]

The kernel itself does not incorporate hwrng output into the rng pool sufficiently

This is not true. Stop saying nonsense.

If you see a bug in the code that would make your statement true, please send a patch to fix that, as I'd consider that an important bug to fix.

[MichaIng]

And why do rng-tools and haveged then exist at all, and are indeed required on most headless server systems which use systemd as init system, if you do not want them to hang in some boot stage?

As said, I have not tested it since a while, but such a daemon became very necessary with the release of Debian Bullseye (or was it Buster?), more precisely the systemd version shipped with it.

[zx2c4]

I think for most uses, those daemons are no longer useful for anything at all and can be safely uninstalled. For a long time, random.c development was stagnant, so userspace had to come up with all sorts of hacks to account for its shortcomings. These days, hwrng output is fed into random.c in the kernel, and it even does a haveged-like jitter thing in desperate scenarios.

[MichaIng]

Quoting myself:

Or has something chanced about this in recent Linux versions?

So you say that indeed something has changed, that is good to know. The released RPi kernel build is 6.1.21, which is sufficiently new for these changes?

I'll do some tests. Would be actually nice to get rid of those userland services, both of them have/had bugs on certain Debian versions with certain architectures.

[zx2c4]

That should be sufficiently new, yes.

[ardbiesheuvel]

d9e79726193346569af7953369a638ee2275ade5 is when we started feeding the kernel entropy pool from hwrng devices without relying on user space