[FFmpeg-devel] [PATCH] Make av_get_random_seed not block when waiting for more entropy

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Wed, Jun 30, 2010 at 04:21:20PM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Wed, Jun 30, 2010 at 10:11:27AM +0100, M?ns Rullg?rd wrote:
>> >> Martin Storsj? <martin at martin.st> writes:
>> >> 
>> >> > On Tue, 29 Jun 2010, Martin Storsj? wrote:
>> >> >
>> >> >> On Tue, 29 Jun 2010, M?ns Rullg?rd wrote:
>> >> >> 
>> >> >> > Martin Storsj? <martin at martin.st> writes:
>> >> >> > 
>> >> >> > > On Tue, 29 Jun 2010, M?ns Rullg?rd wrote:
>> >> >> > >
>> >> >> > >> This will still block if urandom isn't available.  How about this?
>> >> >> > >
>> >> >> > >> From cb60e983c550c2bdffc5fc07075336fb7c465fe9 Mon Sep 17 00:00:00 2001
>> >> >> > >> From: Mans Rullgard <mans at mansr.com>
>> >> >> > >> Date: Tue, 29 Jun 2010 14:22:51 +0100
>> >> >> > >> Subject: [PATCH] Make av_get_random_seed() non-blocking
>> >> >> > >> 
>> >> >> > >> Attempt to read from /dev/urandom and /dev/random with O_NONBLOCK set.
>> >> >> > >> If neither succeeds, proceed with fallbacks.
>> >> >> > >
>> >> >> > > In general, this looks like an even better alternative. Neither fcntl, 
>> >> >> > > F_SETFL, F_GETFL nor O_NONBLOCK are available on windows, though, so they 
>> >> >> > > need to be hidden within some kind of ifdef.
>> >> >> > 
>> >> >> > Cygwin should have them, mingw might not.
>> >> >> > 
>> >> >> > Do /dev/[u]random exist on cygwin/mingw?
>> >> >> 
>> >> >> Don't know about cygwin, but mingw won't have them at least, since it's 
>> >> >> almost plain win32.
>> >> >
>> >> > Would the cleanest fix be to check for fcntl and/or O_NONBLOCK in 
>> >> > configure, and just keep the nonblock setting line within ifdef? That 
>> >> > ought to work correctly on both cygwin and mingw.
>> >> 
>> >> Yes, that's what I was planning to do.
>> >
>> > before you spend more time on this.
>> > There is a possible security issue with using non block mode
>> > namely if we have /dev/*random and not use it we can end up
>> > using a uninitialized variable. Thats an information leak
>> > it could leak from pointers (kills ASLR) to OS/platform or
>> > compiler version or or or ...
>> 
>> That's a valid point.  Ideas what to do instead?  Waiting indefinitely
>> for something random to show up isn't exactly good either.
>
> until an alternative is found waiting indefinitely is the only sane
> thing to do. (leaking information is only faster to getting ones system
> rooted and just returning 0 also seems inappropriate in this case to me)

How about doing something with microsecond time from gettimeofday()?

-- 
M?ns Rullg?rd
mans at mansr.com