From: "Theodore Ts'o" <tytso@mit.edu>
Date: Wed, 4 Oct 1995 17:10:15 -0400
Subject: Re: Random device in 1.3.30 - Oops and some ideas
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
Date: Wed, 4 Oct 1995 19:48:52 +0100 (MET)
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)
> 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.
If a daemon needs some random data and can't wait, that's what /dev/urandom
is for. "Gimme the best thing you've got."
But if a demon needs *random* data, damn it, I think a way to wait for it
is highly desirable. Indeed, I thought that's what /dev/random did in
the first place - it seemed so obvious.
> 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*.
Well, yes, if it is an application, but a non-interactive daemon just has to
wait. Which I think is reasonable.
> Your patch is fairly clean, though as these things go. So I could be
> convinced to add it....
Please be convinced!
- 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.
There are lots of ways to ensure that that is impossible. No good
random number pool implementation (including the one you have now
and the one I sent you) is *hurt* by adding any data uncorrelated with
the existing contents, however the added data is correlated with itself.
It can be useless, but no worse than that.
So this *is* safe.
> 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().
Right. You can't trust data from J. Random user to be random, although
you can accept it on the chance that it *is* random, and will help.
The ioctl() needs to be root-only. (Maybe use the X permission bit?)
You also have to think about the timing issues carefully. For example,
let's say the random pool is empty. If you do the
ioctl(ADD_RANDOM_BITS, 512), then write() the data, if someone read()s
/dev/random between those two calls, the read might succeed even though
there's no entropy there. On the other hand, if the pool is full and
you write() some data, it doesn't actually improve thhe pool's entropy,
no matter what it is. If someone else *then* reads, they'll knock the
pool down to not-full status. The ioctl() restores the pool to full
even though it shouldn't.
Things will have to be done carefully.
-- -Colin