Comment 8 for bug 1318678

Hi,

There is a possible race condition with the device file and the select command.

We have had a very sketchy attempt at a fix at ( this is not a
complete fix as much as working with the observed issue ):

https://github.com/Openand-I/haveged/tree/oi

The main changes can be summarized as:

Generic Linux based OS:

- Create a new random device at /dev/entropy/random to mitigate
possible file based locking issues

- Simply restrict write_wakeup_threshold to 4064 in the code itself.

- Change select to epoll. This has the added advantage of blocking
till there is any actual entropy depletion, immediately replenishing
the pool upon every use. It therefore does not loop when no entropy is
required.

- Two epolls, one for reading and one for writing.

- Overflowing the pool with an extra byte. There is some strange
reasoning behind this as it kinda sorta releases the entropy gathered
by the kernel till time.

Android specific:

- Sleep upon device sleep

- Every 4 hours, a simple touch to the threshold parameters file again
kinda sorta feels like releases entropy gathered by kernel till time.
This can possibly be solved in Linux ( which doesn't sleep ) by
setting read_wakeup_threshold to 8.

Works excellent. Verified using strace.

There some very distinct usability improvements on both Android and
Linux, including GUI responsiveness and network connectivity due to
faster random number generation. Will almost certainly help virtual
machines too as they are entropy starved.

Invited author to take a look at this.

There is still the problem of a very slow (u)random device that slows
the entire Linux ecosystem down. It is recommended instead to replace
the (u)random device according to the fortuna ( at least 5x faster )
patch at:

http://jlcooke.ca/random

Thanks.