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

[James Almer]

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.