Re: [RFC] frandom - fast random generator module

[Jeff Garzik <jgarzik@pobox.com>]

Eli Billauer wrote:
> I suppose you're asking why having a /dev/frandom device at all. Why not 
> let everyone write their own little random generator (based upon 
> well-known C functions) whenever random data is needed.
> 
> There are plenty of handy things in the kernel, that could be done in 
> userspace. /dev/zero is my favourite example, but I'm sure there are 
> other cases where things were put in the kernel simply because people 
> found them handy. Which is a good reason, if you ask me.
> 
> Besides, it's quite easy to do something wrong with random numbers. By 
> having a good source of random data, I suppose we can spare a lot of 
> people the headache of getting their own user-space application right 
> for the one-off thing they want to do.

This is completely bogus logic.  I can use this (incorrect) argument to 
similar push for applications doing bsearch(3) or qsort(3) via a system 
call.

When the _implementation_ requires that a piece of code be in-kernel 
(for performance or security, usually), it is.

In this case, there is no such requirement.  More below.


> But it's really a matter of taste. That's why I bring up the subject here.


Processors are trending towards putting RNG on the CPU.  VIA won't be 
the last, I predict.  When generating random bits is a single 
instruction, "xstore", userspace applications _should_ be directly using 
this.  It should not be in-kernel.  And similarly, if there is no 
requirement that the kernel's entropy pool is used, the userspace 
application _should_ be where the implementation lives.

So, given that trend and also given the existing /dev/[u]random, I 
disagree completely:  /dev/frandom is the perfect example of something 
that should _not_ be in the kernel.  If you want /dev/urandom faster, 
then solve _that_ problem.  Don't try to solve a /dev/urandom problem by 
creating something totally new.

	Jeff