Problem has already been investigated as a side issue in BZ #1785085.  The JITTER rng source uses clock_gettime() to get timing information, and in Hyper-V guests this call has a resolution of 100 nanoseconds, which is too coarse for JITTER rng purposes.  (The code 2 error result means ECOARSETIME.)  The expectation is that if the JITTER rng source used the RDTSC instruction for timing information, it would work correctly in a Hyper-V VM.

Created attachment 1656366 [details]
patch to use rdtsc in jitterentropy

It needs cleanup, but this patch should switch x8664 systems to use rdtsc in userspace for jitterentropy.  I'm traveling right now, so I can't build it, but I wanted to get it to you so you could test it out.

I applied the patch and rebuilt rngd.  With the new version installed, the VM now boots up with the JITTER source working properly, and rngd does not terminate due to lack of any entropy sources. So the patch looks good.

https://github.com/smuellerDD/jitterentropy-library/pull/15

Comitted upstream, will backport when this is approved

In response to comment #6:
1. What is the scope of harm if this BZ is not resolved in this release? Reviewers want to know which RHEL features or customers are affected and if it will impact any Layered Product or Hardware partner plans.
Currently The MS Azure cloud tunes its hypervisor to provide a very coarse granularity clock (as retunrned by ns_gettime), such that the jitter entropy source in rng-tools is unable to get an accurate estimate in the timing variance of load/store operations, and as a result is unusable.  Given that on Guest VMs in public clouds, this source tends to be the only entropy source available, the system entropy pool can be depleted very quickly, resulting in high latenncy during boot. 
 
2. What are the risks associated with resolving this BZ? Reviewers want to know the scope of retesting, potential regressions.
The solution to this problem is to replace the call to ns_gettime in the application with a call to the machines rdtsc instruction, which is available at a much more fine granularity.  The greatest risk to this fix is the possibility that a cloud provider will also limit the granularity of this instruction, re-creating the problem as initially described

3. Provide any other details that meet blocker criteria or should be weighed in making a decision (Other releases affected, upstream status, business impacts, etc).
This issue has already been fixed upstream:
https://github.com/smuellerDD/jitterentropy-library/pull/15
As it has impact on all RHEL releases that use the rngd daemon on cloud providers which limit clock granularity to VMs (currently only Azure, but others may appear in the future)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1202