Red Hat Bugzilla – Bug 1464200
rngd: "read error" warning when attempting to access nonexistent device
Last modified: 2017-09-18 12:15:03 EDT
This was shown during testing of Bug #1421234.
Description of problem:
# rngd -f
# strace -f rngd -f
open("/dev/hwrng", O_RDONLY) = 3
read(3, 0x7fff6adc3880, 16) = -1 ENODEV (No such device)
write(2, "read error\n", 11read error
) = 11
Not sure what part is to blame - either kernel (/dev/hwrng can be opened, but returns -ENODEV on read attempt), or rng-tools (rngd prints "read error" on access to a nonexisting device).
Version-Release number of selected component (if applicable):
kernel is 3.10.0-685.el7.x86_64
100% (may require no HW entropy source to be present)
Steps to Reproduce: see above
no read error message unless a real read error happens
Developer thinks in https://bugzilla.redhat.com/show_bug.cgi?id=1421234#c52 that rngd should error and exit on no HW entropy source. However, the machine used here has RDSEED CPU extension (Xeon E3-1285L v4 @ 3.4GHz), so this does not apply (and the daemon does not auto-exit either). The error message is still shown.
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?
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]
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.
# rngd -f
hwrng: no available rng
Unable to open file: /dev/tpm0
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.