On my system, udev creates a /dev/hwrng device because the machine has a wireless networking card which can supply random input. You can check for this by doing cat /sys/devices/virtual/misc/hw_random/rng_available and /sys/devices/virtual/misc/hw_random/rng_current. However, trying to read from /dev/hwrng *when wifi is off* results in ENODEV (No such device). If the wifi device is up, /dev/hwrng can be read normally and returns some random data as expected. The rngd init script only tests for device existance and not whether it is actually readable which causes rngd to barf on startup when wireless is not up (which it usually isn't at boot). Reproducible: Always Steps to Reproduce: # /etc/init.d/net.bcm0 stop # ls /dev/hwrng /dev/hwrng # cat /dev/hwrng cat: /dev/hwrng: No such device # /etc/init.d/rngd.dist start * Starting hardware RNG daemon... * Failed to start hardware RNG daemon [ !! ] * ERROR: rngd failed to start # /etc/init.d/net.bcm0 start * Bringing up interface bcm0 * Configuring wireless network for bcm0 * bcm0 connected to SSID "foo" # cat /dev/hwrng >/dev/null # <-- this works; do NOT cat random stuff to stdout! # /etc/init.d/rngd start * Starting hardware RNG daemon... [ ok ] Expected Results: I work around this in my init script by introducing the following function: check_rnd_dev() { DEV=$1 ebegin checking device $DEV dd if=$DEV of=/dev/null bs=64 count=1 2>/dev/null eend $? "Device $DEV exists but is not readable. Check /sys/devices/virtual/misc/hw_random/rng_*." } and then testing: elif [ -e /dev/hwrng ]; then check_rnd_dev /dev/hwrng start-stop-daemon --start --quiet --exec /usr/sbin/rngd -- -s ${STEP-64} -t ${TIMEOUT-60} -b -r /dev/hwrng eend $? "Failed to start hardware RNG daemon" This works for the rng-tools-2-r1 init script. The newer (masked ATM) rng-tools-2-r2 is different but from a quick glance may have the same problem The system is a HP Compaq nx6125 laptop which has a Broadcom BCM4318 wireless chip. Kernel used is 2.6.32.1-tuxonice, with the following config options set: zgrep B43 /proc/config.gz CONFIG_B43=m CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y # CONFIG_B43_PCMCIA is not set # CONFIG_B43_SDIO is not set CONFIG_B43_PHY_LP=y CONFIG_B43_LEDS=y CONFIG_B43_HWRNG=y CONFIG_B43_DEBUG=y # CONFIG_B43_FORCE_PIO is not set # CONFIG_B43LEGACY is not set CONFIG_SSB_B43_PCI_BRIDGE=y zgrep HW_R /proc/config.gz CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_TIMERIOMEM is not set # CONFIG_HW_RANDOM_INTEL is not set # CONFIG_HW_RANDOM_AMD is not set # CONFIG_HW_RANDOM_GEODE is not set # CONFIG_HW_RANDOM_VIA is not set
Created attachment 216012 [details] /etc/init.d/rngd new init script trying to work around the issue. This also works in the case: wifi start rngd start (selects hwrng) wifi stop (hwrng becomes unusable) rngd restart (now urandom is selected)
Near-identical code is already implemented in the -r2 init script, which will shortly be available in the -r3 build (-r2 got package.masked due to an issue with the TPM patch).
The entropy in /dev/urandom is derived from the same entropy pool as /dev/random. Using /dev/urandom as an entropy source for /dev/random thus creates a negative feedback loop and isn't preferred. Therefore falling back to /dev/urandom in the absence of a usable /dev/hwrng node is wrong. See bug 292239 for more info. I confirm that this problem still exists with the current version. However, I am not sure what the fix is. Trying to run rngd without a functional hwrng is a bit like trying to run nginx on a VPN before starting OpenVPN. Perhaps configuring openrc (or your favorite init system) to start rngd after turning the wifi card on is what's required here? Even if we fix it in the init script, there is nothing stopping your from turning your wifi off post-init and breaking rngd. The current init script will pass the non functional /dev/hwrng to rngd and it will fail. If we check for this in the init script and receive ENODEV, we will also have to fail. To me, rgnd failing with an unusable hwrng is the expected behavior so I am closing this as WONTFIX. Please feel free to reopen if you have a suggestion and I'd be happy to see this fixed.
