Messages in this thread |  | | From | Paul Gortmaker <> | Subject | Re: CONFIG_RANDOM option for 1.99.2 | Date | Tue, 14 May 1996 17:01:44 +1000 (EST) |
| |
- From "Theodore Ts'o" at May 13, 96 01:09:19 pm
> 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.
|  |