On Mon, 14 Aug 2017 10:24:48 -0700 stan <stanl-fedorauser@xxxxxxxxxxx> wrote: > 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. Well, the behavior is deliberate, but I haven't found the reason for the change yet. 2017-01-18 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d0e5ea343a0f70351428476bcf8715e0731f26a The variable random_min_urandom_seed is not needed any more as it defined the reseeding behavior of the nonblocking pool. Though it is not needed any more, it is left in the code for user space interface compatibility. _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
