linux-kernel - Re: random: /dev/random often returns short reads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0754295f-b10d-21ce-5767-937d1cd79090@linux.intel.com>
Date:   Thu, 19 Jan 2017 19:17:41 -0800
From:   "H. Peter Anvin" <hpa@...ux.intel.com>
To:     Denys Vlasenko <vda.linux@...glemail.com>,
        Theodore Ts'o <tytso@....edu>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: random: /dev/random often returns short reads

On 01/19/17 13:45, Denys Vlasenko wrote:
> On Wed, Jan 18, 2017 at 7:07 PM, Theodore Ts'o <tytso@....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