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

[Michael Niedermayer]

On Wed, Jun 30, 2010 at 10:20:29PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Wed, Jun 30, 2010 at 09:53:55PM +0100, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> > On Wed, Jun 30, 2010 at 09:07:40PM +0100, M?ns Rullg?rd wrote:
> >> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> >> 
> >> >> > On Wed, Jun 30, 2010 at 07:28:16PM +0300, Martin Storsj? wrote:
> >> >> >> On Wed, 30 Jun 2010, M?ns Rullg?rd wrote:
> >> >> >> 
> >> >> >> > Martin Storsj? <martin at martin.st> writes:
> >> >> >> > 
> >> >> >> > > On Wed, 30 Jun 2010, Michael Niedermayer wrote:
> >> >> >> > >
> >> >> >> > >> 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 ...
> >> >> >> > >> thats all usefull information for a attacker
> >> >> >> > >> he only has to saturate /dev/random so it would block
> >> >> >> > >
> >> >> >> > > Could you elaborate on your concern here? The fix he committed tries
> >> >> >> > > both /dev/random and /dev/urandom, and the latter should never block
> >> >> >> > > (afaik), and even in that case I don't see where any uninitialized
> >> >> >> > > variable would be leaked?
> >> >> >> > 
> >> >> >> > If neither of the files exist, or only /dev/random exists and blocks,
> >> >> >> > it will return an uninitialised value.  It changes only on systems
> >> >> >> > that have a blocking /dev/random and no /dev/urandom.
> >> >> >> 
> >> >> >> True, except that we'd use AV_READ_TIME in the not all that rare cases 
> >> >> >> where it is defined. But for that case where it isn't, what about trying 
> >> >> >> /dev/random in blocking mode only if both the others have failed in 
> >> >> >> nonblocking mode?
> >> >> >
> >> >> > possible
> >> >> >
> >> >> > though maybe we could simplify this by asking which combinations actually
> >> >> > exist?
> >> >> 
> >> >> Given that systems without any of the /dev files certainly exist, we
> >> >> definitely need a sensible fallback for this case.  AV_READ_TIME is
> >> >> only defined for a few arches.
> >> >
> >> > i wonder if systems with a blocking random and no urandom
> >> > exist because if not we dont need the non blocking code. We can just
> >> > do blocking reads
> >> 
> >> That doesn't address the question of what to do when both of them
> >> fail to deliver, whether through blocking or nonexistence.
> >
> > no it doesnt address that question. Thats no reason though not to
> > adress the other question
> 
> You're trying really hard to avoid it...  My question must be answered
> whatever the answer to yours is.  The converse is not true.

Nothing must be awnsered and there is no such relation between the questions
as you pretend there is.

Anyway, if nothing is available to generate a random number then the only
sane thing to do is to return 0
it is certainly better than returning uninitialized memory.

now, after awnsering yours lets return to my question

[...]
-- 
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/20100701/1fc752ee/attachment.pgp>