On Sat, Aug 12, 2017 at 06:32:37AM -0700, stan wrote: > Hi, > > 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 > PRNG. > > Thanks. > _______________________________________________ > kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx you might be looking at commit e297a783e41560b44e3c14f38e420cba518113b8. Normally urandom doesn't block, but you're description suggests it is now, and I think that commit introduced that. Neil _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
