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

[Michael Niedermayer]

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)
Besides switching the random file should already have fixd the waiting

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100630/97df8cea/attachment.pgp>