Hello!

It has come to my attention that autopkgtest currently depends on
rng-tools-debian as provider of rng-tools for its VMs to ensure
entropy is available, or something.

If the entropy provider uses the hwrng subsystem (HRNGDEVICE was
set to, or autodetected as, /dev/hwrng), with recent (at least
bullseye/5.10, but I think even 4.x and perhaps older) kernels
this is no longer necessary as a kernel thread polls the active
device. The (sorry for the German) messages 147, 152, 157 in
Debian #504044 contain a bit more info.

For virtio-rng, basically, it ought to suffice to put a line
	virtio_rng
into /etc/initramfs-tools/modules and regenerate the initramfs
and purge rng-tools*. Then, reboot and verify that the node
	/sys/devices/virtual/misc/hw_random/rng_current
says virtio_rng.0 (or similar) even without rng-tools-debian’s
initscript writing that value there.

If this isn’t how you use rng-tools I’d like to hear from you,
perhaps we can find something out.

Note that rng-tools-debian 2.5 (just uploaded) will automatically
not start the dæmon if automatic HRNGDEVICE detection finds hwrng.

Hello Thorsten and thanks for the suggestion. Currently autopkgtest is
used to test systems as old a Ubuntu Trusty, which ships with Linux
3.13, so what you suggest is too modern.

What we could do is skipping installing rng-tools-debian when the kernel
version is new enough: Linux 5.6 made /dev/random non-blocking [1].
However this can cause surprises in the case of container images, as the
kernel version the container image will run on is not known a priori.

Is there a specific reason why you suggest dropping rng-tools-debian,
other than having more minimal testbeds, which is always good?

[1] https://lore.kernel.org/lkml/20200131204924.GA455123@mit.edu/

(tl;dr at the end)

Paride Legovini dixit:

Ah, you test the older systems from a newer host and with newer
autopkgtest packages?

Then that indeed doesn’t yet need changing for now, as…
did not ship a systemd unit and didn’t really need one except for its
use in autopkgtests, so Sven provided one now, and in bookworm there’s
still the initscript→unit generator, so it should be good now.

Looking at the commit introducing the kernel thread, it landed in
3.17, so 3.13 is indeed older than that and needs rngd.

However you need to be careful: the kernel side of this got fixes
later, and one of the bugs to fix was a busy-spin when *both* the
kernel thread *and* rngd were in use, so it’s only safe to run rngd
with either kernels too old for the hwrng kernel thread at all and
kernels new enough to have this fix, but not those in between. Given
nobody has noticed this yet, I suspect that the distro kernels ship
the bugfix, if necessary.

What kind of input do you provide to rngd? Sven saw it got added in…
https://sources.debian.org/src/autopkgtest/5.42/setup-commands/setup-testbed/?hl=586#L586
… but a quick F3 doesn’t show the package being configured in there.
(rng-tools can also be three different versions…)

If it’s just the automatically detected /dev/hwrng, possibly with
virtio-rng as provider, then I’d appreciate if someone could check
that this will still work sufficiently in sid once rng-tools-debian
2.5 is Installed on the architectures in question as it should then
just not start the rngd dæmon.

In that case, you probably should also check all systems, especially
the very old ones, that they can actually use virtio-rng and make it
available as /dev/hwrng, and that that is enabled (the kernel module
is loaded before the rngd init script / unit is run, in your case it
means in the host before the rng-tools package is installed if the
testbed is run as a chroot, and during testbed startup if it is ran
as virtual machine (I add it to /etc/initramfs-tools/modules and re‐
generate the initramfs, but /etc/modules should also work iff kmod
is started before rng-tools… which it is for sysvinit (kmod is in S
while rng-tools-debian is in 2), no idea about systemd. But since
you have $need_update_initramfs already anyway… that would probably
be the best.

You could also install haveged on systems with older kernels, even
in addition to rng-tools, especially if you cannot guarantee that
virtio-rng is always available and usable. Its entropy quality is
questionable but it should help and this is for testing. I’d not do
that for newer kernels, though.

Note that the Donenfeld patches have been backported to at least
4.9 and I *think* that includes the nōn-blocking-ness of /dev/random,
so if /proc/sys/kernel/random/poolsize is 256, you’ll have that. It
only is nōn-blocking after initialisation though, which does need
sufficient entropy.

────────────────────────────────────────────────────────────────────────

tl;dr: so, for as long as you have kernels that old, keep things
as they are.

But do invest some time into checking what the actual input of
rng-tools is and if it’s supposed to be virtio-rng, make sure
that’s available on the testbeds.

bye,
//mirabilos