Description of problem: On each boot, "read error" is reported by rngd. Seems excessive. Version-Release number of selected component (if applicable): rng-tools-5-4.fc22.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot Actual results: 101 copies of this in a row: [ 76.090436] localhost rngd[1217]: read error Expected results: One is enough. Additional info: Both on baremetal and in a vbox VM, exactly 101 copies of this message appear in a row.
Created attachment 996693 [details] journal baremetal
Created attachment 996694 [details] journal vbox
Same problem here. This only happens on F22 for me, it didn't happen on a F21 (same configuration, used fedup to upgrade). This looks like a regression to me. Since the rng-tools package did not change I guess the kernel changed. Note that rngd is critical for crypto so this bug might impact security!
Happens on F21 to me and must be related to some update last week.
Happens on F21 for me also. I'm running a custom compiled 4.2 kernel from koji, so if it is a kernel problem, it is still in the latest kernels. I run audio-entropyd, and it still seems to be working and providing entropy to the pool.
Is this reproducible, e.g. running (rngd -f)? If so, a strace might help; or add errno logging to rngd_entsource.c:xread. I don’t see a loop like that, but strace suggests that this happens if you don’t have a real entropy source (in particular when rdrand is not available): With kernel-4.0.6-300.fc22.x86_64, open("/dev/hwrng", O_RDONLY) succeeds, but reads from that file fail with -ENODEV. rngd only uses the open() return value to check whether the entropy source is “available”, so instead of quitting with “no sources” it enters the main loop, and then it takes the 100 failures to quit. With just glancing at the kernel change log, I suspect http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/char/hw_random/core.c?id=ac3a497f13e42a99ed6fe188ebf2dcc39eb7ac20 : before, the /dev/hwrng device existed only if a HW RNG was available; now the device always exists and open() succeeds, but read() fails.
(In reply to Miloslav Trmač from comment #6) > Is this reproducible, e.g. running (rngd -f)? If so, a strace might help; or > add errno logging to rngd_entsource.c:xread. it is and it looks like your diagnosis was correct. ... open("/dev/hwrng", O_RDONLY) = 3 ... read(3, 0xbfd59738, 2500) = -1 ENODEV (No such device) write(2, "read error\n", 11read error ) = 11 write(2, "\n", 1 ) = 1 read(3, 0xbfd59738, 2500) = -1 ENODEV (No such device) write(2, "read error\n", 11read error ) = 11 write(2, "\n", 1 ) = 1 read(3, 0xbfd59738, 2500) = -1 ENODEV (No such device) write(2, "read error\n", 11read error
This is still a bug in Fedora 23, rng-tools-5-5.fc23.
Created attachment 1068323 [details] strace rngd -f
Do you know if this leads to system freezing at boot? My system froze at the boot and there were a lot of these lines. Does it only work on systems that have hardware random number generator? How do I tell if my system has a random number generator. I am using Fedora 23 KDE on Thinkpad T420.
I doubt that this is the cause of freezing on boot. It's a needless timeout, but other than wasting CPU shouldn't cause problems. It's possible there is some race condition being spawned, but unlikely. If you have one of the later intel cpus, it has a built in hardware random number generator. You can look that up online, searching with your cpu type. Other than that, you have to install an hrng in order to have one. If you haven't, you don't. You could look at the modules the kernel has loaded, lsmod, and see if any of them are drivers for an hrng. I *think* that the default Fedora kernel builds all of them, so if you have an hrng, the module should load. You can use audio-entropyd, a program from the Fedora repositories to feed the entropy pool. You need a spare audio device, or one used infrequently, so that the program has the time to gather the entropy. You can also use rtl2832-entropyd, from sourceforge, as a program to feed the entropy pool. This requires that you buy an rtl2832 (less than $10 on ebay), and blacklist the default linux kernel module for the rtl2832, as it is to use it for listening to radio, the original purpose of the rtl2832, rather than as a source of entropy. If present, the default kernel module will stop the entropy daemon from acquiring the device. These aren't kernel hrngs, so you have to load and run them yourself. Using lots of sources of entropy is a good plan, as it thwarts attacks. The intel hrng is reputed to be very good, but it *could* have an engineered back door. Feeding even a little uncorrelated entropy into the kernel pool would scramble such a scheme.
@stan Thanks for the info. I am using an i7-2620M processor. Looks like my system doesn't have Intel Secure Key looking at the Intel processor page[1]. Would disabling rndg.service be the best course of action for my system? audio-entropyd and rtl2832-entropyd would not require rndg.service. Is that correct? [1] http://ark.intel.com/products/52231/Intel-Core-i7-2620M-Processor-4M-Cache-up-to-3_40-GHz
@Sudhir I agree, your cpu doesn't have the rng on it. If you want to get rid of the messages, disabling would be fine. On my system, without any hrng, systemctl -a -t service shows that rngd is loaded, but inactive and dead. So, it isn't doing anything. But I have both audio-entropyd and rtl2832-entropyd running, and they are feeding the kernel entropy pool. They do this through a direct call from outside the kernel, so not having the rngd service running is irrelevant to them. Hmmm, maybe I can disable rngd also. How do I know they are feeding it? I do, as root, cat /proc/sys/kernel/random/entropy_avail, and see that the entropy is being maintained at the higher value I have set (3800, max is 4096), and also seeing them periodically run in top. They have verbose options, also, that have them log their updates to the system logs. These show up in journalctl, so it can be seen how often they run and how much entropy they are adding. When I first installed them, I checked these, but leave them turned off for normal operation to reduce the messages they generate.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still a problem with Fedora 23, Fedora 24, and Rawhide.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
Still happens on rawhide. # journalctl -b | grep error Sep 06 06:42:07 mirrors.cicku.me rngd[1245]: read error Sep 06 06:42:07 mirrors.cicku.me rngd[1245]: read error ...
rng-tools-5-8.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d41b24b4a2
rng-tools-5-8.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-031e0211c0
the stupid read errors are gone but others are back Oct 20 16:08:12 srv-rhsoft rngd: /dev/hwrng: No such device Oct 20 16:08:12 srv-rhsoft rngd: /dev/tpm0: No such file or directory is it really that hard to shutup this service on a ordinary IvyBridge machine with "rdrand" instructions especially when it's started with "/usr/sbin/rngd --quiet -f" where "--quiet" is a pretty clear statement?
rng-tools-5-8.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
rng-tools-5-8.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.