[lkml]   [2003]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] frandom - fast random generator module
On Oct 16, 2003  07:29 -0400, Jeff Garzik wrote:
> 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.
> 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.

Actually, there are several applications of low-cost RNG inside the kernel.

For Lustre we need a low-cost RNG for generating opaque 64-bit handles in
the kernel. The use of get_random_bytes() showed up near the top of
our profiles and we had to invent our own low-cost crappy PRNG instead (it's
good enough for the time being, but when we start working on real security
it won't be enough).

The tcp sequence numbers probably do not need to be crypto-secure (I could
of course be wrong on that ;-) and with GigE or 10GigE I imagine the number
of packets being sent would put a strain on the current random pool.

Cheers, Andreas
Andreas Dilger

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.158 / U:0.100 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site