On Mon, 14 Aug 2017 09:55:00 -0700 stan <stanl-fedorauser@xxxxxxxxxxx> wrote: > On Mon, 14 Aug 2017 08:26:34 -0400 > Neil Horman <nhorman@xxxxxxxxxx> wrote: > > > 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. > > > > 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 > > > I'm not sure that's correct. That commit seems to be for something > else. > > https://github.com/torvalds/linux/commit/e297a783e41560b44e3c14f38e420cba518113b8 > > It's creating a function to ensure any call to get random bytes blocks > until there is enough entropy to ensure valid random data is returned. > But that isn't what I'm seeing. There is no call to the blocking > function, and both /dev/random and /dev/urandom yield results > immediately. This is about the behind the scenes transfer of entropy > from the kernel entropy pool to urandom in order to reseed the > generator when the kernel entropy pool is full or nearly so. It used > to do that, it no longer does. > > I don't see how that can even be a side effect of this change. That > transfer of entropy is a core relationship of the /dev/urandom PRNG > with the /dev/random entropy pool. This is part of the functionality I'm talking about, from random.c: if (crng_init < 2 && entropy_bits >= 128) { crng_reseed(&primary_crng, r); entropy_bits = r->entropy_count >> ENTROPY_SHIFT; It was the most recent hit from a search of the commit site for crng_reseed. _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
