Re: Continuing /dev/random problems with 2.4

Andreas Dilger (adilger@turbolabs.com)
Fri, 1 Feb 2002 12:57:03 -0700


On Feb 01, 2002 13:38 -0600, Ken Brownfield wrote:
> Of course, in my case deleting the /dev/random character node still
> doesn't allow entropy to drain in (after at least a month) so I suspect
> the kernel's entropy generation would be sufficient if it didn't
> artificially stall or drain from within the kernel.

Hmm, you may also need to delete /dev/urandom too. Reading from
/dev/urandom will also deplete the entropy pool just as much as
reading from /dev/random. The only difference is that /dev/random
will block if there aren't enough bits as requested, while reads
from /dev/urandom will happily continue to return data which isn't
"backed" by any entropy.

You could also enable debugging in drivers/char/random.c to see what
is going on (it may be very verbose). You could even change the one
message in extract_entropy() to include the command name, like:

DEBUG_ENT("%s has %d bits, %s wants %d bits\n",
r == sec_random_state ? "secondary" :
r == random_state ? "primary" : "unknown",
current->comm, r->entropy_bits, nbytes * 8);

(not sure of exact usage for current->comm, but you could use ->pid
instead).

Note that even traffic over the network will deplete your entropy
pool, because it is using secure_tcp_sequence_number() and secure_ip_id().
Also, using SYN cookies appears to increase the amount of entropy used.

Cheers, Andreas

--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/