Messages in this thread | | | Subject | Re: random: /dev/random often returns short reads | From | "H. Peter Anvin" <> | Date | Thu, 19 Jan 2017 19:17:41 -0800 |
| |
On 01/19/17 13:45, Denys Vlasenko wrote: > On Wed, Jan 18, 2017 at 7:07 PM, Theodore Ts'o <tytso@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. >
That seems to make sense to me as well.
-hpa
| |