I compile a custom kernel locally from the Fedora src.rpm.  I notice
that the most recent 4.13 kernel I compiled, 4.13.0-0.rc4.git3.1, has
different behavior for the kernel entropy pool than it used to have.

The way it used to work was that when the kernel entropy pool was kept
full, or fuller, it would bleed entropy across to the pseudo-random
generator in order to reseed it.  This makes the output sequence of the
PRNG indeterminate, and thus more random, and harder to attack.  It is
no longer a pseudo random number generator, except in intervals.

I notice now that there is no bleed happening.  When the kernel entropy
pool gets full, if there are no calls to /dev/random, it stays full.

I don't have a hardware RNG, but I harvest entropy from a sound device,
and from an rtl2832 receiver (atmospheric).  They still work, if I do
cat /dev/random | rngtest -b 10
they get fired up and run full out.

But if I do 
cat /dev/urandom | rngtest -b 20000
the entropy pool just sits there, and they don't run.

The entropy pool can be looked at, as root, with
cat /proc/sys/kernel/random/entropy_avail
I reset the write_wakeup_threshold there to 3840 from its default 1792,
and lower the urandom_min_reseed_secs to 5 (I think the default is 60).

Can you explain why this was changed, or point me to a discussion of
the rationale for the change?  It seems like it has implications for
system security, and on the surface seems to decrease security of the

kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Reply via email to