Bug 1973646

hello, Marian,

apologies, i'm not sure why do you suggest that virtio_rng should be replaced in the rhel8.
it works on my rhel8 kvm vm quite well:

# uname -r
4.18.0-305.el8.x86_64

# ls -la /dev/hwrng
crw------- 1 root root 10, 183 Jun 22 11:30 /dev/hwrng

# cat /sys/devices/virtual/misc/hw_random/dev 
10:183

# cat /sys/devices/virtual/misc/hw_random/rng_available
virtio_rng.0 

probably this device has to be added to the vm itself in its config. i'm using standard
qemu + libvirtd + virt-manager on my laptop and it is done in vm details -> Add Hardware.
i'm not sure about other platforms.

as for rng-tools - yes, with the introduction of jitter-rng in the kernel as of v5.4-rc1
by 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it")
we generally have enough entropy in all cases (except when some application requires massive
amounts of entropy) and do not need rngd to run in userspace anymore. thus Fedora and RHEL
have removed rng-tools from the installed-by-default standard and minimal package sets (but
rng-tools surely can be installed if necessary).

> where does the rrand cpu feature come into play? Noticed the following in dmesg;

as for this, this was added in the RHEL8.3 (since kernel-4.18.0-201.el8) and RHEL8.2.z
per bz1830280 and bz1928027.

please, note, CONFIG_RANDOM_TRUST_CPU enabled by the patch in these bzs just enables
trusting CPU (namely, its RDRAND command on x86_64) as a source of randomness by default.
the setting random.trust_cpu={on,off} itself was available since the upstream v4.19-rc3.

no update for a week, closing.