[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:

>> There are systems, many in fact, without /dev/[u]random or
>> AV_READ_TIME.
>
> yes but the question was about blocking /dev/random and non existing
> /dev/urandom at the same time.  (or a unrealistic blocking
> /dev/urandom)
>
> open(/dev/urandom)
> if(fail)
>     open(/dev/random)
> read()
>
> is sufficient if such system does not exist

Fine, let's dig.

First up, OpenBSD:

     /dev/random    This device is reserved for future support of hardware
                    random generators.

     /dev/srandom   Strong random data.  This device returns reliable random
                    data.  If sufficient entropy is not currently available
                    (i.e., the entropy pool quality starts to run low), the
                    driver pauses while more of such data is collected.  The
                    entropy pool data is converted into output data using MD5.

     /dev/urandom   Same as above, but does not guarantee the data to be
                    strong.  The entropy pool data is converted into output
                    data using MD5.  When the entropy pool quality runs low,
                    the driver will continue to output data.

     /dev/arandom   As required, entropy pool data re-seeds an ARC4 generator,
                    which then generates high-quality pseudo-random output
                    data.

FreeBSD:

     The random device returns an endless supply of random bytes when read.
     It also accepts and reads data as any ordinary (and willing) file, but
     discards data written to it.  The device will probe for certain hardware
     entropy sources, and use these in preference to the fallback, which is a
     generator implemented in software.

NetBSD:

     Reading from /dev/random will only return values while sufficient entropy
     exists in the internal pool.  When sufficient entropy does not exist,
     EAGAIN is returned for non-blocking reads, or the read will block for
     blocking reads.

     Reading from /dev/urandom will return as many values as requested, even
     when the entropy pool is empty.  This data is not as good as reading from
     /dev/random since when the pool is empty, data is still returned, degen-
     erating to a pseudo-random generator.

Solaris 10, AIX 6.1, HP-UX:

     /dev/random and /dev/urandom like Linux.

Plan9:

     Reads from random return a stream of random numbers. The numbers
     are generated by a low priority kernel process that loops
     incrementing a variable. Each clock tick the variable is sampled
     and, if it has changed sufficiently, the last few bits are
     appended to a buffer. This process is inefficient at best
     producing at most a few hundred bits a second. Therefore, random
     should be treated as a seed to pseudo-random number generators
     which can produce a faster rate stream.

Windows (non-cygwin):

     No /dev/*random devices.

MacOSX, confusingly:

     The random device produces uniformly distributed random byte
     values of potentially high quality.

     /dev/urandom is a compatibility nod to Linux. On Linux,
     /dev/urandom will produce lower quality output if the entropy
     pool drains, while /dev/random will prefer to block and wait for
     additional entropy to be collected.  With Yarrow, this choice and
     distinction is not necessary, and the two devices behave
     identically. You may use either.

OS/2, DOS, etc:

     No /dev/*random.

GNU HURD:

     No /dev/*random by default, various hacks suggested.

BeOS, Haiku:

    Definitive information hard to find, some kind of /dev/random
    device appears to exist.

Various embedded systems:

    No filesystem at all.

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