![]() | |||||||||||||
Messages in this thread |
David McCullough wrote: > Jivin Jeff Garzik lays it down ... > >>David McCullough wrote: >> >>>Jivin Jeff Garzik lays it down ... >>> >>> >>>>On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote: >>>> >>>> >>>>>Hi all, >>>>> >>>>>Here is a small patch for 2.6.11 that adds a routine: >>>>> >>>>> add_true_randomness(__u32 *buf, int nwords); >>>>> >>>>>so that true random number generator device drivers can add a entropy >>>>>to the system. Drivers that use this can be found in the latest release >>>>>of ocf-linux, an asynchronous crypto implementation for linux based on >>>>>the *BSD Cryptographic Framework. >>>>> >>>>> http://ocf-linux.sourceforge.net/ >>>>> >>>>>Adding this can dramatically improve the performance of /dev/random on >>>>>small embedded systems which do not generate much entropy. >>>> >>>>We've already had hardware RNG support for a while now. >>>> >>>>No kernel patching needed. >>> >>> >>>Are you talking about /dev/hw_random ? If not then sorry I didn't see it >>>:-( >>> >>>On a lot of the small systems I work on, /dev/random is completely >>>unresponsive, and all the apps use /dev/random, not /dev/hw_random. >>> >>>Would you suggest making /dev/random point to /dev/hw_random then ? >> >>All the apps are supposed to use /dev/random, so that's correct. > > > Ok > > >>For Hardware RNGs, userspace rngd daemon obtains entropy, checks it >>(mainly checking for hardware failures), and then stuffs entropy into >>the kernel random device. http://sf.net/projects/gkernel/ >> >>On the "to do" list is making rngd directly generate entropy use >>'xstore' on VIA CPUs, rather than going kernel -> userland -> kernel. >> >>Also, there are other entropy daemons floating about. I think there is >>one that obtains noise from an audio device. > > > I had looked at hw_random, but it seemed a little platform specific (x86), > and it doesn't currently have a way for RNG providers to register themselves. > Admittedly I did not know how it's output was being used in practice. > > The drivers I am working with do crypto/public key and RNG. Not all of > them can easily have the RNG support taken from the driver and plugged > into hw_random.c, since it is (in most cases) a single PCI chip with > it's own registers, initialisation and configuration, that, IMO > belongs in the driver for the particular chip. Agreed. > Not that it isn't possible, but hw_random would start supporting a > much larger number of HW variants and I think it would get ugly. Agreed. > It would be possible to add a "register" interface to hw_random so that > you can register other RNG's easily. This would seem reasonable. Agreed. > I work on fairly resource constrained embedded devices a lot of the > time, so when I can avoid adding applications and reduce kernel size, > I do. Thus my motivation to add a simple API for adding entropy to > /dev/random. We already have the facilities to add entropy, as current use of hw_random+rngd shows. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-04-06 13:30 [from the cache] ©2003-2008 | |||||||||||||