/dev/io , /dev/mem : only used by Xorg?

[Ted Mittelstaedt]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Loren M. Lang
> Sent: Tuesday, March 01, 2005 9:12 PM
> To: Ted Mittelstaedt
> Cc: FreeBSD questions; Loren M. Lang; Rob; Kris Kennaway
> Subject: Re: /dev/io , /dev/mem : only used by Xorg?
>
>
> I don't seem to have rndcontrol on 5.3, is that an old command?
>

I think you missed the back and forth on this between me and Kris?

answer, no - the random device in 5.3 was rewritten to probe for
ethernet and other random irq's

> >
> > Another strange thing is that /dev/random should block when it
> > runs out of entropy - it doesen't seem to do so, however.  And the
> > device doesen't seem to gain entropy that quickly.
>
> Then how is /dev/random differ from /dev/urandom?
>

The current philosophy in random devices is to make both of these be
the same, and use a better random number generator that generates random
numbers faster, thus removing the need for separate devices.

Here is a section of the readme from the Solaris patch 112439-02 which
adds a
random device to Solaris 2.6, it illustrates the typical older behavior
of the two devices:

     Applications retrieve random bytes by reading /dev/random or
     /dev/urandom. The /dev/random interface returns random bytes
     only when sufficient amount of entropy has  been  collected.
     If  there  is  no entropy to produce the requested number of
     bytes,  /dev/random  blocks  until  more  entropy   can   be
     obtained.  Non-blocking  I/O mode can be used to disable the
     blocking behavior. The /dev/random interface  also  supports
     poll(2). Note that using poll(2) will not increase the speed
     at which random numbers can be read.

     Bytes retrieved from /dev/random provide the highest quality
     random numbers produced by the generator, and can be used to
     generate  long  term  keys  and  other  high  value   keying
     material.

     The  /dev/urandom interface returns bytes regardless of  the
     amount  of  entropy  available.  It does not block on a read
     request due to lack of entropy. While bytes produced by  the
     /dev/urandom  interface are of lower quality than bytes pro-
     duced by /dev/random, they are nonetheless suitable for less
     demanding  and shorter term cryptographic uses such as short
     term session keys, paddings, and challenge strings.

You see, the problem with this from an application developers perspective
is that if you are designing an app that MUST only use high quality
random numbers, then you have to read /dev/random not /dev/urandom -
but if /dev/random's prng runs out of randomness, it will block, thus
your application hangs until it unblocks.  If you try to get around that
by reading in nonblocking mode then your app won't hang, but you will
get an error when the device runs out of numbers and you try to keep
reading it.  Thus your app will still have to set waiting around for
more numbers.  /dev/urandom allowed app developers to ignore all that
because then the /dev/urandom device runs out of random numbers it
just gives non-random numbers - while this of course makes your app
insecure, most app developers don't give a shit since their customers
don't know any better.

FreeBSD did away with the blocking in /dev/random because a number of
app developers didn't understand I/O and the FreeBSD core group got
tired of hearing the complaints - reasoning (correctly) that if the
app developer didn't bother to understand anything about random number
generators then it didn't make any difference if the device fed them
non-random numbers on occasion.

> >
> > The FreeBSD random device is a port of the same Linux code.
>
> I'm pretty sure that the linux code is GPLed, and I'd expect that
> FreeBSD uses a BSD version.  Are they actually from the same code?
>

Yes they are.  However the author of the code, Theodore Ts'o, was well
aware of the problems of GPL when he wrote it, and released the code
with effectively 2 licenses, one BSD the other GPL.

Of course Linux people subsequently applied the GPL to their version
but that doesen't affect us, see the file /usr/src/sys/kern/kern_random.c
in FreeBSD 4.

There is at least one other random device that was written for Solaris
that uses this code also.  (andi's SUNrand) I also strongly suspect that
Sun
used this code in their patch 112439 since my testing of the Sun device
and the
FreeBSD device showed they fell down almost the same way.

The 5.X random generator is a different animal, it is based on the
Yarrow prng as well as more sensible hardware detection and use.

Keep in mind that until 1995 when everyone started using UNIX servers
for running SSL webservers on the Internet, almost nobody gave a damn
about needing a random device under UNIX or any other operating system.

>
> Every doc I've heard of using prng on linux always suggests that the
> native entropy source is better?  Is this because the linux version has
> better hooks in the kernel and always uses interrupts as a source?
>

The docs your reading are wrong or not really telling the whole story.

For starters it isn't possible in a computer to get a source of
randomness by just looking at interrupts, that will generate
random numbers as fast as they are needed.  Random devices (ideally)
use interrupts as inputs to pseudorandom number generators
(prngs) which are able to generate much larger quantities of random
numbers
at a much higher rate of speed.  So it still boils down to who has
the best algorithm for the prng.

if the native random device uses a simple prng that cannot generate
random numbers as fast as needed, even if the inputs to it are random,
such as an interrupts, then it isn't going to be as good as a
non-native prng that uses the same random inputs and uses a better
algorithm.

Ted