When testing the random device by reading it in several processes
at the same time, I got an Oops message, here is the output from
ksymoops:
I can't duplicate it with my current random driver (using /dev/urandom
instead of /dev/random), but there have been a lot of changes made to
that code already....
- add blocking mode for /dev/random where it blocks until enough
random bytes are read or the read is interrupted by a signal (this
is what my patch below does), to get the old behaviour, open with
the O_NONBLOCK flag. I hope it is not too late to make this change
since the random device just appeared in 1.3.30 and nobody except
those on the bleeding edge should be using it yet... We usually
need certain amount of random data so I think blocking mode would
be useful.
I'm not convinced this is useful. A daemon who calls this on an idle
machine, where there is no disk or keyboard activity, will end up
blocking forever.
I would think it would be better for the application program to decide
what to do if there's not enough randomness --- perhaps tell the user to
pound on the keyboard, if they're on the console, or *something*.
Your patch is fairly clean, though as these things go. So I could be
convinced to add it....
- make it possible to add randomness by writing to /dev/random.
Suppose you have a noise generator connected to a D/A converter
(like a zener diode, coupled to the microphone input of a sound
card) - a daemon could read noise samples from /dev/audio, and
write them to /dev/random, and programs using /dev/random don't
need to know about any other devices, and automatically get more
randomness more quickly.
I've been meaning to do this ---- however, note that /dev/random had
better be protected mode 644; you don't want anybody being able to write
into /dev/random, since an attacker who wished to put malicious data
into the entropy pool might be able to do something interesting.
Also, it's not just a matter of writing into /dev/random; you also need
to somehow update the estimate of how much entropy you've added into the
system. Probably this would have to be done via an ioctl().
I'll probably get around to this eventually, but other things are higher
on my priority list, at least at the moment.....
- Ted