Linux RNG device, random device, and pseudo-random device are all inaccessible

[nima]

This is the .travis.yml file I used for showing the problem:

before_script:
  - echo "#. Bug report START -={"
  - uname
  - ls -l /dev/urandom /dev/random /dev/hwrng
  - sudo /usr/sbin/rngd -r /dev/urandom -f || echo FAILED urandom
  - sudo /usr/sbin/rngd -r /dev/random -f  || echo FAILED random
  - sudo /usr/sbin/rngd -r /dev/hwrng -f   || echo FAILED hwrng
  - echo "#. Bug report END }=-"
  - exit 1

And here is the output:

$ echo "#. Bug report START -={"
#. Bug report START -={
$ uname
Linux
$ ls -l /dev/urandom /dev/random /dev/hwrng
crw------- 1 root root 10, 183 Jan 30 12:43 /dev/hwrng
crw-rw-rw- 1 root root  1,   8 Jan 30 12:42 /dev/random
crw-rw-rw- 1 root root  1,   9 Jan 30 12:42 /dev/urandom
$ sudo /usr/sbin/rngd -r /dev/urandom -f || echo FAILED urandom
cant open /dev/random: Operation not permitted
FAILED urandom
$ sudo /usr/sbin/rngd -r /dev/random -f  || echo FAILED random
cant open /dev/random: Operation not permitted
FAILED random
$ sudo /usr/sbin/rngd -r /dev/hwrng -f   || echo FAILED hwrng
cant open /dev/hwrng: Operation not permitted
FAILED hwrng
$ echo "#. Bug report END }=-"
#. Bug report END }=-
$ exit 1

[BanzaiMan]

This probably supersedes #1495. My initial guess is that we probably won't support it.

@roidrage @joshk @svenfuchs Opinions?

[nima]

From #1495:

To be honest, it's probably better to use /dev/urandom on the VMs.

I don't mind not having a real RNG - the problem is that I get the same "Operation not permitted" error when trying to use `/dev/urandom' - using this device would speed up tests considerably, and leave alone the host VMs entropy pool for more important things.

[sarahhodne]

The problem is that rngd is trying to open /dev/random to write entropy to it, which isn't allowed since this entropy pool is shared across the VMs on the same host.

I'm not sure if it's possible to somehow “disconnect” /dev/random from the host and have a VM-local entropy pool, but that might be a solution for this.

[nima]

Okay, here is a workaround for this issue: remove the existing /dev/random device as that is tied to the VM hypervisor, and regardless of what rngd options you specify, rngd will try and open that device in rw mode.

Next, create /dev/random as a pseudo-random device via sudo mknod -m 0666 /dev/random c 1 9 - this device generates fake random data fast, does not require an actual entropy source, and has no ties to the VM hypervisor (therefor can be written to).

Install a replacement /etc/default/rng-tools that reads:

RNGDOPTIONS="--random-device /dev/urandom --rng-device /dev/urandom"

Tell apt for dpkg to not prompt or replace existing configuration files that are supplied by package (in a file such as /etc/apt/apt.conf.d/99TravisUnitTestOverrides)

Dpkg::Options:: "--force-confdef";
Dpkg::Options:: "--force-confold";

Finally, install the rng-tools package.

My builds/tests are now down to under 2 minutes (from 7+ minutes) - yay!

Again - this isn't a fix obviously, just a workaround - so hopefully the implementation of what @henrikhodne suggested will be what closes this ticket :)

[roidrage]

@henrikhodne do you think this is worth investigating further or is the workaround sufficient?

[xolox]

I guess I just went through the same ordeal that dozens of Travis CI users have experienced, trying to get an entropy hungry part of my test suite to run to completion without timing out on inactivity.

1. First I tried installing rng-tools and
   adding HRNGDEVICE=/dev/urandom to /etc/default/rng-tools. It failed to start and the build timed out (as explained elsewhere OpenVZ creates a read only /dev/random preventing rng-tools from working).
2. Then I tried something completely different: generating a lot of disk I/O. That didn't help at all, my builds were still timing out.
3. Then I tried the suggestion by @nima, however rng-tools failed with the error message /dev/urandom: Permission denied.
4. Finally I combined both rng-tools experiments and got it to work!

Here's my working .travis.yml. Thanks to @nima for coming up with a solution! Now I can finally focus on improving my software again :-)

[garrettr]

@xolox you are a god among men

[BanzaiMan]

On GCE, I believe haveged (http://packages.ubuntu.com/precise/haveged; http://packages.ubuntu.com/trusty/haveged) is good for this purpose. Install it, start the service, and read from /dev/random. (https://github.com/jruby/jruby/wiki/FAQs#slow_rvm_install_entropy)

[zenczykowski]

You can now get virtio-rng on GCE:
https://bugzilla.redhat.com/show_bug.cgi?id=1572944#c79