[FFmpeg-devel] [PATCH] lavu/random_seed: use getrandom() when available

[Marton Balint]

On Sun, 9 Jul 2023, James Almer wrote:

> On 7/9/2023 1:23 PM, Marton Balint wrote:
>>
>>
>>  On Sun, 9 Jul 2023, Anton Khirnov wrote:
>>
>>>  Quoting Marton Balint (2023-07-07 22:02:26)
>>>> 
>>>>
>>>>  On Fri, 7 Jul 2023, Anton Khirnov wrote:
>>>>
>>>>>  It is a better interface for /dev/u?random on Linux, which avoids the
>>>>>  issues associated with opening files.
>>>> 
>>>>
>>>>  getrandom() actually have the same problem as read(). It can read less
>>>>  than requested. So you should use it in a loop in that case or if it
>>>>  returns EINTR.
>>>
>>>  I'm not convinced it's actually a problem.
>>>
>>>  This API is intended for small secrets like keys and such, somebody
>>>  trying to generate vast quantities of random data is likely misusing it
>>>  and could just as well use LFG or something.
>>>
>>>  Failing in that case seems like a good thing to me.
>>
>>  This is a very bad argument. If the API should not be used for big
>>  secrets, then it should always fail for size > 256 or something, not
>>  sometimes fail. And such limitation should be documented.
>>
>>  And its not just about big secrets. EINTR can be returned for small
>>  secrets as well, and you should handle it.
>>
>>  I also question if it is a good idea to use the non blocking mode. Imagine
>>  a situation when somebody wants to automatically start a command line
>>  after boot which needs a key. It might fail right after boot, but will
>>  work after a couple of minutes. IMHO it is better to block (1-2 minute
>>  tops) than making the function sometimes work, sometimes not.
>
> If we make the urandom/getrandom() path block and potentially take 1-2 
> minutes, then I'd prefer if it's last in the function, after all available 
> external implementations (Some of which can fail) were tried first.

It will take 1-2 minutes if it is right after boot and if the system has 
no support for quickly gathering entropy via some hardware feature...

So it is not like /dev/random. It only waits until the CSPRNG of 
/dev/urandom initializes. I doubt external libraries can come up something 
significantly quicker, since they are also using the same system provided 
randomness for initialization...

Regards,
Marton