Bug 1464200

this isn't going to make 7.4 at this point, moving to 7.5

You're initial comment is convoluting several items 

1) The "read error" message will appear now anytime the hwrng is opened, if a backing hardware rng is not present (which seems to be the case on this system).  Note the presence of the RDSEED extensions does not constitue the availability of a hwrng (at least not by default, it may be possible to tell the kernel to use RDSEED as a hwrng, but that doesn't happen by default)

2) The lack of exit is expected here, because the use of RDSEED is independently configured by rngd.  That is to say, it will both look for RDSEED availability and /dev/hwrng as rng sources, along with a tpm.  Only if none of those are available, will rngd exit for lack of an entropy source.  Since you have RDSEED availability, it should run fine, which it sounds like it is.  If you want to observe it exiting, run rngd with the -d option.

All in all this sounds like its working as designed, with the possible exception of the read error on attempting to setup a non-existant /dev/hwrng.  Do you just want that error removed?

Hi Neil,

I'll throw in my unsolicited 2 cents... I think perhaps a more detailed error message (or messages? if we want different scenarios to report different errors) might be good here.

This is how I understand it:
Is there a good reason that open() on /dev/hwrng succeeds, but read() attempts return -ENODEV?
Yes -> please remove the rngd error message in that case, as this is expected behavior
No -> please fix the device, so that -ENODEV is returned on open(); then let's re-test how rngd handles that

In answer to your first question, yes, because the underlying hwrng can be altered at run time, and so the device may change at any time, up until a user space process opens it and takes a reference to it.  However, removing the error isn't valid as a lack of hwrng implementation isn't something that can be recovered from dynamically (i.e. we should inform the user and exit).

If we remove the error, we remove the error in all cases, even when its legitimate (i.e. we later find we also dont have rdseed and exit), implying silent failure.  It also eliminates the possibility of detecting errors at run time, if the hwrng fails at some later point in its use.

About the only thing we can really do here is eliminate the error message, and only print it after we init the entropy source successfully, and then encounter an error during normal operation, but it involves changing some of our fips initialization code, and I'm hesitant to do that as I don't know what the impact will be on fips certification.

We can try it for the purpose of testing, but I'm not sure it will be a legitimate solution

Created attachment 1295857 [details]
test patch

Yes, it would be better if rngd matched kernel's logic and checked for appearing and disappearing entropy sources on an open hwrng device. But if we cannot implement this, then your patch is much better than nothing, as nonexisting HW entropy source won't mix with the other "read error"s anymore. Thanks, will test the patch.

What more info are you requesting?

the results of the test, please, i've not had time to run it yet.

Looks good:

# rngd -f
hwrng: no available rng
Unable to open file: /dev/tpm0
^C

ok, so at this point I guess the thing to do is wait for pm ack so they can decide what the fips impact is

Did no vmware testing. Not sure if you have the same issue, or another read error. Perhaps you could find something interesting in "strace -f rngd -f" ?

the "read error" is codified within rngd itself.  The patch here will fix the vmware issue as well.  The only culpability the kernel has here is triggering when rngd triggers the read error, and is doing so validly.

(In reply to Neil Horman from comment #17)
> the "read error" is codified within rngd itself.  The patch here will fix
> the vmware issue as well.  The only culpability the kernel has here is
> triggering when rngd triggers the read error, and is doing so validly.

Thanks Neil, I would be waiting for patch.

- Vishal Agrawal.

*** Bug 1518376 has been marked as a duplicate of this bug. ***

I had to install 7.3 to reproduce the original behavior - "read error" in loop multiple times, no other output. 7.4 prints the error just once, even on the same machine, together with extra information about entropy sources it tries to access, 7.5 does not print the error, just even more extra information:

RHEL 7.3:
[root@dell-per210-01 ~]# rpm -q rng-tools
rng-tools-5-8.el7.x86_64
[root@dell-per210-01 ~]# rngd -f
read error

read error
...

RHEL 7.4:
[root@dell-per210-01 ~]# rpm -q rng-tools
rng-tools-5-11.el7.x86_64
[root@dell-per210-01 ~]# rngd -f
read error

hwrng: no available rng
Unable to open file: /dev/tpm0
can't open any entropy source
Maybe RNG device modules are not loaded


RHEL 7.5 Beta:
[root@dell-per210-01 ~]# rpm -q rng-tools
rng-tools-5-13.el7.x86_64
[root@dell-per210-01 ~]# rngd -f
Failed to init entropy source 0: Hardware RNG Device

Failed to init entropy source 1: TPM RNG Device

Failed to init entropy source 2: Intel RDRAND Instruction RNG

can't open any entropy source
Maybe RNG device modules are not loaded


----

Not sure why I could not reproduce the original behavior on 7.4, just on 7.3 . I might had been using a 7.4 beta version of rng-tools that got patched before it got released as final 7.4, but did not find the corresponding patch in git. Anyway, this is not that important, as the problem is clearly fixed in 7.5, and the error message does not show anymore.

Setting verified.

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-2018:0698

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days