> The original reason I didn't provide a CONFIG_RANDOM was because I
> wanted security-oriented applications (i.e., Netscape, PGP, Kerberos,
> etc.) to be able to assume that if they were on Linux, /dev/linux would
> always be present. Good, secure numbers are absolutely vital for
> programs that rely on cryptography. The most secure encryption system
> in the world is useless if the attacker can guess the random numbers you
> used to generate your crypto keys....
I do understand that good random numbers are needed for crypto keys.
However, I don't think that just because some applications *may* be
changed to use the /dev/random device justifies dictating that all
users must have the /dev/random device present.
If we take that approach, then we should remove the CONFIG_PROC_FS
option, as lots of applications require it (ps, w, xload, SNMP-tools,
arp, etc. etc. etc.). Next to go is CONFIG_SYSVIPC, as many things
like tape-buffer programs, the games from ID (doom, abuse) and whatnot
expect that functionality to be present. Also, we might as well remove
both CONFIG_BINFMT_AOUT and CONFIG_BINFMT_ELF, and make both mandatory,
so that commercial vendors can rest assured that one binary will work
on all linux systems.
I'm not being completely sarcastic with the above, as removing these
would have the advantage of removing some of the kernel <--> application
interdependency that exists as in the above examples.
The disadvantage is that all these little blocks of code quickly add
up to take a substantial chunk of memory. The typical "off-the-shelf"
computer still only comes with 8MB RAM installed, and it would be
bad if linux becomes too bloated to be viable for use on such a common
target. Alan reported earlier that 1.2.13(+kswap) was usable on a 4MB
box, but recent 1.3.x kernels were painful to use in 4MB.
I also thought of some other issues relating to security type
applications that could use /dev/random, which I will quickly mention.
First of all, *if* applications like NetScape and PGP decide to use
/dev/random, and an open on it returns ENODEV, they can fall back onto
whatever code that is used at present for randomness on any unix.
Secondly, they will *have* to do the above to ensure that the
application can run on the huge installed base of v1.2.x kernels
out there that do not have a /dev/random.
Also, I suspect that where security is involved, people such as the
NetScape crew will be reluctant to use something like /dev/random
over their own internal code, simply because it is code that is not
under their control, and thus represents a substantial risk for them.
(I have left Kerberos out of the above argument, because I suspect Ted
has already improved it to make it "/dev/random" aware....)
> Note that if you just need input values to "crashme", a
> non-cryptographically secure random number generator would be all that
> you need.
That was meant as a joke, but don't worry I'll use /dev/urandom ;-)
> The random driver also isn't all that big, and the overhead of the
> add_XXX_randomness() calls were designed to be as small as possible.
The random driver is actually one of the largest char drivers, with
only console.o and serial.o being bigger in a typical configuration.
The overhead of the add_XXX_randomness() calls may also be small, but
small is different from negligible. I just checked with a 486-33 and
a five year old WD 80MB IDE disk, and was able to generate in excess
of 150 add_blkdev_randomness() calls per second. Faster disks would
of course easily surpass this call rate. I'd have to play with the
profiling tools to see what this costs in CPU time, but it might be
an issue for a heavily loaded ftp server. If you aren't using the
/dev/random device then it is just wasted cycles regardless.
[ possible bug report follows ]
Also note that the floppy and IDE driver *look like* they use the
add_irq_randomness() because they use a SA_SAMPLE_RANDOM flag with
the call to request_irq(). But they also use SA_INTERRUPT, which means
using do_fast_IRQ() which correctly avoids calling add_irq_randomness(),
as it is only called inside do_IRQ(). In other words, using
SA_INTERRUPT|SA_SAMPLE_RANDOM is functionally equivalent to SA_INTERRUPT.
So to this point in time, it appears that *nobody* has used
add_irq_randomness() yet.
Paul.