Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Evgeniy Polyakov wrote:
On Thu, 2005-03-24 at 23:23 +1000, David McCullough wrote:

Jivin Jeff Garzik lays it down ...

Evgeniy Polyakov wrote:

On Thu, 2005-03-24 at 14:27 +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.


People will not apply any kind of such changes.
Both OCF and acrypto already handle all RNG cases - no need for any kind
of userspace daemon or entropy (re)injection mechanism.
Anyone who want to use HW randomness may use OCF/acrypto mechanism.
For example here is patch to enable acrypto support for hw_random.c
It is very simple and support only upto 4 bytes request, of course it
is not interested for anyone, but it is only 2-minutes example:

If you want to add entropy to the kernel entropy pool from hardware RNG, you should use the userland daemon, which detects non-random (broken) hardware and provides throttling, so that RNG data collection does not consume 100% CPU.

If you want to use the hardware RNG directly, it's simple: just open /dev/hw_random.

Hardware RNG should not go kernel->kernel without adding FIPS tests and such.

For reference,  the RNG on the Safenet I am using this with is
FIPS140 certified.  I believe the HIFN part  is also but I place the doc that
says so.


At least HIFN 795x is certified.

Idea to validate entropy data is good in general, but it should be implemented in a way allowing external both in-kernel
and userspace
processes to contribute data.
So for in-kernel use we need such a mechanism, and userspace gkernel
daemon
should use it(as the latest "step") too.

See the earlier discussion, when data validation was -removed- from the original Intel RNG driver, and moved to userspace.


Your changes are correct, ioctl(RNDADDENTROPY) could even use it instead
of direct
add_entropy_words()/credit_entropy_store(), but without external entropy
contributors
it will not be applied by maintainers.

No changes are needed, as the system is currently functional without these changes.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux