Messages in this thread |  | | Date | Wed, 29 May 1996 11:14:01 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: CONFIG_RANDOM (compromise?) |
| |
From: Albert Cahalan <albert@ccs.neu.edu> Date: Tue, 28 May 1996 23:03:02 -0400 (EDT)
On a 386SX-16? My guess: value*clockchange*arch = 0.000008*(75/16)*(2*1.5) = 0.0001 Now, multiply that by the number of calls. At 1000/second, the system would be spending maybe 10% of the time getting entropy. That is of course a wild guess, but it's better than a BogoMIPS-based estimate.
While I was doing my benchmarking, I tried my hardest to generate as many entropy samples as possible. The best I could do was about 100 calls per second. So on a 386SX-16, using your estimates, we're talking about 1% of the time --- and that was when the hard disk was going full bore. (And on a 386SX-16, it's likely that your disk transfer will probably be much less, so the number of entropy cycles will probably much less than 100/second.)
It shows one aspect of performance. You could get a better picture by running a CPU benchmark at the same time.
OK, let's take a look at the facts, and do some quick calculations. Using the average of 600 cycles/per call, and your 100 calls/second, then on a 50 MHz Pentium, the overhead is 0.12% of the CPU. If we assume your architecture multiplier of (2*1.5), then on a 386SX-16 the CPU overhead is approximately 1.1%. Permit me not to be terribly impressed. (Again, on a 386-SX the I/O bandwidth on the bus will likely be bad enough that you won't be able to get 100 calls to end_request()/second.)
> It might be possible to move the complicated hash function (which is > used when you actually read from /dev/random) out to a user-mode daemon, > but you wouldn't be able to move out to a library, because of user to > user security concerns. (A random user program can't be allowed to > directly see random pool, since that would completely compromise the > security of the random pool.) The real problem with a user-mode daemon,
With a library alone: You wouldn't keep the old pool after giving it to a user.
With a library alone, then the user program could access the pool directly, this violating the pool's security. We can't restrict the user program to only using the library abstraction interface. This is why your proposed library solution is completely inadequate.
Since the networking protocols require SHA and MD5, those must be in the kernel. The particular way that Linux boots is not an ISO or RFC anything, so that can be changed. It should be simple to write a program that replaces the gzip CRC (and magic) with something else. Maybe the FSF would even accept an alternate algorithm to be used only when gzip is explicitly told to do so. For now though, a simple hack_gz_for_linux could switch to MD5 or SHA.
The point of this statement is that the SHA checksum is approximately 6796 bytes of text. This is out of the 10385 bytes of text used by the random driver. So if the network code in the future requires SHA, then the total net savinges of ripping out the random driver is an amazing 3589 bytes --- less that one page.
It continues to amaze me how people like to rip apart other people's code without even stopping to do any real thinking and investigation. After all this complaining and kvetching about kernel bloat and overhead, when we actually take a close look at it, it's not all that bad at all.
- Ted
|  |