On Wed, Jan 18, 2017 at 7:07 PM, Theodore Ts'o <ty...@mit.edu> wrote: > In the ideal world, yes. I've acknowledged this is a bug, in the "be > conservative in what you send, liberal in what you receive" sense.. > But no one complained for three year, and userspace needs to be able > to retry short reads instead of immediately erroring out. > > The problem is changing that code to figure out exactly how many bytes > you need to get in order to have N random bytes is non-trivial. So > our choices are: > > 1) Transfer more bytes than might be needed to the secondary pool, > which results in resource stranding --- since entropy in the secondary > pool isn't available for reseeding the CRNG. OTOH, given that we're > now using the CRNG solution, and we're only reseeding every five > minutes, I'm not actually all that worried about stranding some extra > entropy bits in the blocking pool, since that's only going to happen > if we have people *using* the /dev/random pool, and so that entropy > will likely be used eventually anyway ... ... > I'm leaning a bit towards 1 if we have to do something (which is my > proposed, untested patch).
Thanks, this solution is okay for me.
