![]() | |||||||||||||
Messages in this thread |
Evgeniy Polyakov wrote: > On Thu, 2005-03-24 at 15:39 -0500, Jeff Garzik wrote: > >>Evgeniy Polyakov wrote: >> >>>hw_random.c already does it using userspace daemons, >>>which is bad idea for very fast HW - like VIA xstore/xcrypt >>>instructions. >> >>This is incorrect, because it implies that a user would want to use the >>'xstore' feature at full speed -- which would dominate the CPU, >>drastically slowing down the applications that are actually doing work. > > > If user want to get RNG data at full speed we do not want to allow it? > Something changed in the world... I agree with this sentiment; this is mainly a policy decision that kernel programmers should not make. Certainly _by default_ the RNG should not be run "full blast" all the time. This is a needless CPU soaker. This is another example of why the userspace rngd is useful: it is trivial to implement "CPU soaker" policy if you wish, or use the default "don't eat all my CPU" policy. > User actually do not want to use xstore, but only read from /dev/random. That's a policy decision to be made by the user, not you. Some users may wish to use RNG directly. > If kernelspace can assist and driver _knows_ in advance that data > produced is cryptographically strong, why not allow it directly > access pools? A kernel driver cannot know in advance that the data from a hardware RNG is truly random, unless the data itself is 100% validated beforehand. 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 | |||||||||||||