Haveged entropy gathering daemon (new package) or rngd.service by default

[pddenhar]

Haveged

Haveged allows generating randomness based on variations in code execution time on a processor.

• Package upstream repo: https://github.com/jirka-h/haveged
• Gentoo ebuild: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/haveged

Impact of adding this package to the Flatcar OS image

• This package meets the requirements of Flatcar Container Linux’ new package guidelines: https://github.com/flatcar-linux/Flatcar/blob/master/adding-new-packages.md

• The package improves on the following core values:

  • Secure by default
  • Always up to date
  • Improve container experience
  • Operate at scale / automation / telemetry

The package will increase the OS image by: 80 KBytes.

The package will potentially increase Flatcar’s attack surface:

• The quality of the entropy generated by haveged can be variable if your virtual hosting provider traps the instructions used to generate it. DigitalOcean does not seem to have this problem, and recommends HAVEGED. I suggest making HAVEGED optional, and disabled by default.

Benefits of adding this package to the Flatcar OS image
Booting Flatcar on some virtual hosting providers without a reliable source of hardware entropy (mouse, keyboard, disk interrupts) can take a very long - and variable - time.

Booting Flatcar on DigitalOcean sometimes takes >3 minutes before the Docker daemon is started because the system blocks until enough entropy is gathered ( random: crng init done - related StackExchange here: https://unix.stackexchange.com/questions/442698/when-i-log-in-it-hangs-until-crng-init-done).

Running haveged in a Docker container (like https://github.com/harbur/docker-haveged) is not an option, since Docker daemon itself is blocked from starting by the lack of available entropy.

Allowing Flatcar users on virtual hosting providers with constrained entropy to enable HAVEGED via an ignition config would help reduce the problem of Flatcar hosts occasionally hanging on boot for multiple minutes while entropy is gathered.

[pothos]

Hi,
thank you for the proposal, worth exploring, also whether it should be part of the initramfs.

I also see that rngd.service is not enabled by default, did you try to enable it and check for the existence of /dev/hwrng on your machines? (Edit: It should be active in the initramfs already, so maybe we just have to enable it for the system. This makes probably sense if we assume it has a different backing than cat /sys/class/misc/hw_random/rng_current)

[pddenhar]

Thank you for the suggestion, I had assumed that there was not HW RNG support on my host (DigitalOcean) because of open issues requesting it (https://ideas.digitalocean.com/ideas/DO-I-2147) but sudo rngd -v does actually report an available entropy source:
Available entropy sources: Intel/AMD hardware rng

I'll have to do more research to make sure this is available on all of our hosts, but this is a very good interim solution. Thank you for the suggestion.

[pothos]

Did you check what /dev/random is based on? head /sys/class/misc/hw_random/rng_*
The /dev/hwrng device should be the visualized HW random device then and be picked up by rngd.

Good, curious to hear back. As first result of this request here I would at try to enable rngd by default but we keep can keep the request open to consider haveged for corner cases.

[pothos]

To repeat the part that was not done yet: possible enable rngd.service by default (if we assume it has a different backing than the ones in /sys/class/misc/hw_random/rng_current)

Adding havegd as new package can be discussed but I would not do it unless really needed

[pothos]

We decided to drop even rngd because since kernel 5.4 the issue of early-boot blocking is resolved and now with the upcoming kernels even /dev/random will just behave like /dev/urandom.