The simplest and a proper way to do that is systemctl presets.
As of now they enable rngd both in Fedora and RHEL8:

# grep -ri rng /usr/lib/systemd/system-preset/ /usr/lib/systemd/user-preset/
/usr/lib/systemd/system-preset/90-default.preset:enable rngd.service

We need to change "enable" to "disable" or remove this line.
Probably we need to create the same bz for Fedora.

The 2 similar bzs (bz1578833 and bz1215645) have "redhat-release{,-sever}"
component, I believe this one should go there too.

fedora/rawhide's copy of the same:
https://bugzilla.redhat.com/show_bug.cgi?id=1888823

> With the introduction of jitter-rng in the kernel as of 8.3

being:
upstream: 50ee7529ec45 random: try to actively add entropy rather than passively wait for it
rhel-8.3: edc3002c84e7 [char] random: try to actively add entropy rather than passively wait for it

fedora solved it in bz1888823#c3 by not installing rng-tools by default and not touching presets:

https://pagure.io/fedora-workstation/issue/184
https://pagure.io/fedora-comps/pull-request/533

probably, RHEL can do the same (AFAIK, RHEL uses comps.xml too).

I like the fedora solution, not installing the rng-tools by default but keeping the presets and I agree witch comment 4 from rhbz#1888823

> Agreed, if people wish to install it I think it's useful to be enabled by default if there's an available HW RNG.

Switching component to releng as a proposal.

Sounds good to me. Thanks Petr!

I'm not sure it was a smart decision to not install rng-tools by default on servers. This is what I brought to the CentOS mailing list:

...
On a new test install of EL9 I saw this message in the logs:

Mar 01 08:09:18 <hostname> pcp-pmie[2870]: Low random number entropy
available 15.6%...

This is on a 64 core "AMD Opteron(tm) Processor 6282 SE" server but I also
got the same low entropy on an EL9 KVM guest running on a "AMD EPYC 7601"
server.

After a lot of searching the net I understand that rng has been reworked
in 5.x kernels and /proc/sys/kernel/random/entropy_avail reaches only 256
in default configurations. But why does it go too low on a test system
with almost not load?

Is this an issue with AMD CPUs or does it also happen on other systems?
...

I'm afraid many users may not realize that their random number entropy goes low and therefore may experience low performance but don't find it out.

At least for server installs rng-tools should be installed in case the hardware requires it IMHO.

I'm not talking about laptops here but for servers, my test boxes are from HPE and Gigabyte, it really hurts to end up with a system running low on entropy.

Thanks,
Simon

(In reply to Simo Sorce from comment #0)
> With the introduction of jitter-rng in the kernel as of 8.3 we generally
> have enough entropy in all cases and do not need rngd to run in userspace
> anymore.

Unfortunately this is not the case and it appears to be causing problems:

https://bugzilla.redhat.com/show_bug.cgi?id=2176255

The RHEL8 kernel only collects CPU jitter during the boot initialisation stage, it does not use CPU jitter at all once the kernel RNG has finished initialisation.  So on a system that is otherwise starved of entropy, the RHEL8 kernel will soon block on /dev/random when left on its own.

This is quite different from the RHEL9 kernel behaviour where /dev/random has been completely replaced with /dev/urandom.

Thanks, Herbert,
With that, we should think about adding rng-tools installed by default
back in RHEL8. There were problems in FIPS mode mentioned in bz1884857,
but they were resolved. Also, bz2154804 has disabled rng-tools in FIPS
mode.

Any reason why we should not feed jitter-rng into /dev/random after boot on the RHEL-8 kernel ?

To add to Simon Matter’s comment about the need for rng-tools in a virtual machine context –

rngd may also fail to initialise the Jitter source (a fix is to extend the timeout: https://access.redhat.com/solutions/6984027), or it could happen that neither hwrng nor rdrand is available. In either case, one can instead opt for jitterentropy-rngd, either as an RPM through the copr repo (and forthcoming in EPEL8) or compiled directly from source.