Intel 810 Random Number Generator

[sottek]

All,
  As a first attempt at kernel programming I've written a driver for
the Hardware Random number generator available on Intel 810 systems.
If anyone cares, I can provide a document in which Intel waves all
copyrights and grants me right to do whatever I please with this
code which was developed on my own time (I am an Intel employee).

  In it's current state it compiles and runs against kernel 2.3.X
(AFAIK) but isn't really useful. Here's the theory of operation, and
some ideas for making it useful. Some of these ideas were already
discusses with Alan and Ted (without code) before I had the waver.

 The RNG is basically just a couple registers one of which will give you
a random byte every 4ms or so, the public docs say it comes from thermal
entropy on the chip, and I have no other information about it's source
but I do know that it seems to always pass statistical randomness tests.
(more later)

 This driver uses a device file (insmod rng.o rng_major=? rng_minor=?)
that will allow you to read a stream of random bytes, it blocks if 
none is available but is pretty fast (more like 4bytes per 4ms in
testing). Also, once per jiffie (maybe should be less) the RNG reads
a byte on its own and adds it to it's internal stat tests. After 2500
byte have been read it check to see if the results pass the FIPS 140-1
RNG tests and if they don't it disables the RNG. Ted had mentioned his
concern that the RNG would freak out under some unknown circumstances
and start producing non-random data. This internal test prevents this.

  There is also a /proc/sys/dev/rng that identifies the RNG and tells
you it's state. `echo -n 0  > /proc/sys/dev/rng` disables it
 `echo -n 1  > /proc/sys/dev/rng` re-enables it. (Disable it before
doing rmmod)

Current Problems:
#1 It has a device file which is a bad idea. We don't want people using
the data directly, and we don't want them to NOT use /dev/random. The
better way is to get the data into the entropy pool for /dev/random.
Ted's opinion was to read from the RNG in user land and put the data
into /dev/random through ioctl's. My opinion is that if the data is
available to user land someone will use it directly. Plus the overhead
of all the ioctl's and context switches has to be more than if we had
an exported add_random_byte() function from random.c.
(Note that Ted has not seen the implementation described here so I don't
want to speak for him)

#2 This is my first shot in kernel land so pointers are appreciated,
I've not messed with 2.2.X although I included some compatibility macros
for once I get around to it.

#3 Holding the stat test information in the kernel might be a waste. It
isn't much space and doesn't grow so I think we're OK. I may be able to
trim it down some too. If this isn't done in the kernel then we run the
risk of giving either users or the entropy pool bad data.

Solutions:
#1 Make random.c export a function to the kernel that takes in raw
random data and adds it to the entropy pool without doing any work on
it. This is a trust issue, we have to assume that people in the kernel
have better ways to mess with the machine than adding non-random data
to the pool. If this existed the device file would go away and the
rng.o module would just call add_random_byte() once per jiffie, no-one
would even know it was running.

#2 Keep the /dev/<whatever> and have a user daemon that reads data out
and puts it back in the kernel through the ioctl on /dev/random. This
would make lots of ioctls and would require the user space daemon. Plus
it leaves a /dev/rng laying around for people to [mis]use.


 I've attached the source, you can send me kernel help if you feel like
it, but mostly I'd like to get a consensus on the best way to make this
work.

 -Matt Sottek
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: rng.c
Type: application/octet-stream
Size: 11996 bytes
Desc: no disponible
URL: <https://lists.srvr.mx/pipermail/ayuda/attachments/20000124/8406cc83/attachment.obj>