Re: [PATCH] btrfs-progs: utils: use better wrappered random generator

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-05-25 07:11, David Sterba wrote:
> On Wed, May 25, 2016 at 08:33:45AM +0800, Qu Wenruo wrote:
>>
>>
>> David Sterba wrote on 2016/05/24 11:51 +0200:
>>> On Tue, May 24, 2016 at 08:31:01AM +0800, Qu Wenruo wrote:
>>>>> This could be made static (with thread local storage) so the state does
>>>>> not get regenerated all the time. Possibly it could be initialize from
>>>>> some true random source, not time or pid.
>>>>
>>>> I also considered true random source like /dev/random, but since it's
>>>> possible to wait for entropy pool, it would be quite slow and confusing
>>>> for users.
>>>
>>> How would it be confusing? We'll once seed the random generator from
>>> /dev/random, reading 3 * 16bit for the nrand generator context.
>>
>> Reading from /dev/random may sleep, until the entropy pool is filled.
>
> I know, but does this apply in our case? We're going to get just a few
> bytes to seed.  I want to avoid inventing own random number generation
> schemes, so we'll use a standard random number source or API.
>
> /dev/random gives about 1-2MB/s of random data on several machines I've
> tried.
You have a lot of systems with a lot of spare entropy then, or you 
unintentionally added a 'u' at the beginning of 'random' and were only 
testing on slow systems.  Some people (myself included) do seed 
/dev/random from hardware RNG's or other daemons (I run both HAVEGE and 
rngd), but many people don't, and a majority of embedded systems I've 
seen absolutely don't.  48-bits may not seem like much, but if we're 
using /dev/random, it has the potential to block indefinitely, and 
having that possibility in end-user software is not a good thing.

I would tend to agree with Hugo on this one, we should be using 
/dev/urandom, not /dev/random.