From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: David McCullough <davidm@snapgear.com>
Cc: cryptoapi@lists.logix.cz, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
James Morris <jmorris@redhat.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Date: Thu, 24 Mar 2005 14:59:11 +0300 [thread overview]
Message-ID: <1111665551.23532.90.camel@uganda> (raw)
In-Reply-To: <20050324042708.GA2806@beast>
[-- Attachment #1: Type: text/plain, Size: 6854 bytes --]
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:
--- ./drivers/char/hw_random.c.orig 2005-03-24 13:36:05.000000000 +0300
+++ ./drivers/char/hw_random.c 2005-03-24 14:48:30.470407432 +0300
@@ -34,6 +34,10 @@
#include <linux/smp_lock.h>
#include <linux/mm.h>
#include <linux/delay.h>
+#include <linux/acrypto.h>
+#include <linux/crypto_def.h>
+#include <linux/crypto_stat.h>
+#include <linux/highmem.h>
#ifdef __i386__
#include <asm/msr.h>
@@ -73,6 +77,8 @@
#endif
#define RNG_MISCDEV_MINOR 183 /* official */
+
+static DEFINE_SPINLOCK(rng_lock);
static int rng_dev_open (struct inode *inode, struct file *filp);
static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size,
@@ -482,7 +488,6 @@
static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size,
loff_t * offp)
{
- static DEFINE_SPINLOCK(rng_lock);
unsigned int have_data;
u32 data = 0;
ssize_t ret = 0;
@@ -526,7 +531,109 @@
return ret;
}
+#define CONFIG_ACRYPTO
+#ifdef CONFIG_ACRYPTO
+static struct crypto_device *hwr_cdev;
+static struct crypto_capability hwr_caps[] = {
+ {CRYPTO_OP_RNG, 0, 0, 100},
+};
+
+static void hwr_data_ready(struct crypto_device *dev)
+{
+ struct crypto_session *s, *n;
+ unsigned long flags;
+ u32 data = 0;
+ unsigned int have_data;
+ u8 *ptr, *optr;
+
+ local_irq_save(flags);
+ if (spin_trylock(&dev->session_lock)) {
+ local_irq_restore(flags);
+ return;
+ }
+
+ list_for_each_entry_safe(s, n, &dev->session_list, dev_queue_entry) {
+ if (!session_completed(s) && !session_is_processed(s)) {
+ start_process_session(s);
+ spin_lock(&rng_lock);
+ have_data = 0;
+ if (rng_ops->data_present()) {
+ data = rng_ops->data_read();
+ have_data = rng_ops->n_bytes;
+ }
+ spin_unlock (&rng_lock);
+
+ optr = ptr = kmap_atomic(s->data.sg_dst[0].page, KM_USER0) + s->data.sg_dst[0].offset;
+ while (s->data.sg_dst[0].length && have_data) {
+ *ptr++ = data & 0xff;
+ s->data.sg_dst[0].length--;
+ have_data--;
+ data >>= 8;
+ }
+ kunmap_atomic(optr, KM_USER0);
+
+ if (s->data.sg_dst[0].length)
+ broke_session(s); /* Need proper work deferring, see async_provider.c as example. */
+
+ crypto_stat_complete_inc(s);
+ crypto_session_dequeue_route(s);
+ complete_session(s);
+ stop_process_session(s);
+ }
+ }
+
+ spin_unlock(&dev->session_lock);
+ local_irq_restore(flags);
+}
+
+static int hwr_acrypto_init(struct rng_operations *ops)
+{
+ int err;
+
+ hwr_cdev = kmalloc(sizeof(*hwr_cdev), GFP_KERNEL);
+ if (!hwr_cdev) {
+ printk(KERN_ERR "Failed to allocate new crypto_device structure.\n");
+ return -ENOMEM;
+ }
+
+ memset(hwr_cdev, 0, sizeof(*hwr_cdev));
+
+ hwr_cdev->cap = hwr_caps;
+ hwr_cdev->cap_number = sizeof(hwr_caps)/sizeof(hwr_caps[0]);
+ hwr_cdev->priv = ops;
+ hwr_cdev->data_ready = &hwr_data_ready;
+ snprintf(hwr_cdev->name, sizeof(hwr_cdev->name), "%s", "hwr");
+
+ err = crypto_device_add(hwr_cdev);
+ if (err) {
+ kfree(hwr_cdev);
+ hwr_cdev = NULL;
+ return err;
+ }
+
+ printk(KERN_INFO "%s acrypto support is turned on.\n", hwr_cdev->name);
+
+ return err;
+}
+
+static void hwr_acrypto_fini(void)
+{
+ crypto_device_remove(hwr_cdev);
+ printk(KERN_INFO "%s acrypto support is turned off.\n", hwr_cdev->name);
+ kfree(hwr_cdev);
+ hwr_cdev = NULL;
+}
+#else
+static int hwr_acrypto_init(struct rng_operations *ops)
+{
+ return 0;
+}
+
+static void hwr_acrypto_fini(void)
+{
+}
+#endif
/*
* rng_init_one - look for and attempt to init a single RNG
@@ -549,9 +656,15 @@
goto err_out_cleanup_hw;
}
+ rc = hwr_acrypto_init(rng_ops);
+ if (rc)
+ goto err_out_misc_unregister;
+
DPRINTK ("EXIT, returning 0\n");
return 0;
+err_out_misc_unregister:
+ misc_deregister(&rng_miscdev);
err_out_cleanup_hw:
rng_ops->cleanup();
err_out:
@@ -617,6 +730,8 @@
{
DPRINTK ("ENTER\n");
+ hwr_acrypto_fini();
+
misc_deregister (&rng_miscdev);
if (rng_ops->cleanup)
So, one may use crypto_session_alloc(gimme_real_randomness) and that is
all
(either from userspace or kernelspace).
As far as I can see, OCF support is also very simple.
What I want to say, is that since OCF and acrypto already support
all RNG cases, it is better to port existing drivers to them, but
not the reverse.
That will allow to use both old hw_random.c driver and
any new one(HIFN, VIA, safenet, any other) without breaking any
interfaces from both userspace and kernelspace.
If one of the asynchronous crypto layers will be included,
/dev/random implementation can be changed to support it.
> Cheers,
> Davidm
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-03-24 11:54 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-15 13:36 ocf-linux-20050315 - Asynchronous Crypto support for linux David McCullough
2005-03-24 4:27 ` [PATCH] API for true Random Number Generators to add entropy (2.6.11) David McCullough
2005-03-24 4:30 ` [PATCH] API for true Random Number Generators to add entropy (2.4.29) David McCullough
2005-03-24 4:33 ` [PATCH] API for true Random Number Generators to add entropy (2.6.11) Jeff Garzik
2005-03-24 4:46 ` David McCullough
2005-03-24 4:49 ` Michal Ludvig
2005-03-24 5:13 ` Jeff Garzik
2005-03-24 12:37 ` Folkert van Heusden
2005-03-24 12:52 ` David McCullough
2005-03-24 20:51 ` Jeff Garzik
2005-03-24 7:18 ` Jan Engelhardt
2005-03-24 7:37 ` Dave Jones
2005-03-24 4:38 ` [PATCH] " Andrew Morton
2005-03-24 5:17 ` Jeff Garzik
2005-03-24 5:32 ` Andrew Morton
2005-03-29 1:33 ` Matt Mackall
2005-03-24 5:43 ` Randy.Dunlap
2005-03-24 12:21 ` Evgeniy Polyakov
2005-03-24 20:39 ` Jeff Garzik
2005-03-25 4:25 ` Evgeniy Polyakov
2005-03-25 4:45 ` Jeff Garzik
2005-03-25 5:46 ` Herbert Xu
2005-03-31 3:52 ` David McCullough
2005-03-31 13:58 ` [PATCH] API for TRNG (2.6.11) [Fortuna] Jean-Luc Cooke
2005-04-13 15:36 ` Jean-Luc Cooke
2005-03-24 12:28 ` [PATCH 2.6.12-rc1] API for true Random Number Generators to add entropy David McCullough
2005-03-24 12:38 ` [PATCH] API for true Random Number Generators to add entropy (2.6.11) David McCullough
2005-03-24 18:51 ` Andi Kleen
2005-03-24 20:37 ` Jeff Garzik
2005-03-27 17:19 ` Andi Kleen
2005-03-27 18:55 ` folkert
2005-03-28 15:20 ` Andi Kleen
2005-03-28 15:24 ` folkert
2005-03-29 7:17 ` Jeff Garzik
2005-03-29 15:03 ` Andi Kleen
2005-03-29 7:16 ` Jeff Garzik
2005-03-29 15:07 ` Andi Kleen
2005-03-29 7:15 ` Jeff Garzik
2005-03-24 11:59 ` Evgeniy Polyakov [this message]
2005-03-24 12:48 ` Jeff Garzik
2005-03-24 13:08 ` Evgeniy Polyakov
2005-03-24 20:53 ` Jeff Garzik
2005-03-24 13:23 ` David McCullough
2005-03-24 13:46 ` Evgeniy Polyakov
2005-03-24 20:56 ` Jeff Garzik
2005-03-25 4:34 ` Evgeniy Polyakov
2005-03-25 4:48 ` Jeff Garzik
2005-03-25 5:33 ` Evgeniy Polyakov
2005-03-25 5:58 ` Jeff Garzik
2005-03-25 6:16 ` Evgeniy Polyakov
2005-03-25 6:13 ` Herbert Xu
2005-03-25 6:34 ` Evgeniy Polyakov
2005-03-25 6:33 ` Herbert Xu
2005-03-25 6:59 ` Evgeniy Polyakov
2005-03-25 6:56 ` Herbert Xu
2005-03-25 7:19 ` Evgeniy Polyakov
2005-03-25 7:19 ` Jeff Garzik
2005-03-25 7:38 ` Evgeniy Polyakov
2005-03-25 7:25 ` Herbert Xu
2005-03-25 7:58 ` Evgeniy Polyakov
[not found] ` <424495A8.40804@freescale.com>
2005-03-25 23:43 ` Jeff Garzik
2005-03-25 23:47 ` Herbert Xu
2005-03-26 0:47 ` Evgeniy Polyakov
2005-03-26 0:36 ` Herbert Xu
2005-03-26 8:52 ` Evgeniy Polyakov
2005-03-28 13:45 ` Jean-Luc Cooke
2005-03-28 21:30 ` Herbert Xu
2005-03-29 10:23 ` Pavel Machek
2005-03-29 10:21 ` Pavel Machek
2005-03-29 10:30 ` Herbert Xu
2005-03-29 10:38 ` Pavel Machek
2005-03-29 10:45 ` Herbert Xu
2005-03-29 10:50 ` Evgeniy Polyakov
2005-03-29 10:46 ` Herbert Xu
2005-03-29 11:42 ` Evgeniy Polyakov
2005-03-29 11:39 ` Herbert Xu
2005-03-29 12:15 ` Evgeniy Polyakov
2005-03-29 12:13 ` Pavel Machek
2005-03-29 12:43 ` Herbert Xu
2005-03-29 13:11 ` Evgeniy Polyakov
2005-03-29 14:38 ` Evgeniy Polyakov
2005-03-29 13:48 ` Jean-Luc Cooke
2005-03-29 23:36 ` Andrew James Wade
2005-03-29 22:02 ` Bill Davidsen
2005-03-29 22:24 ` Kyle Moffett
2005-03-29 22:46 ` Jeff Garzik
2005-03-30 21:22 ` Bill Davidsen
2005-03-30 21:49 ` Jeff Garzik
2005-03-30 22:27 ` Paul Jackson
2005-03-29 10:18 ` Pavel Machek
2005-03-29 10:25 ` Herbert Xu
2005-03-29 10:53 ` Martin Mares
2005-03-24 20:54 ` Jeff Garzik
2005-03-24 14:25 ` Jean-Luc Cooke
2005-03-24 20:57 ` Jeff Garzik
2005-03-24 21:20 ` Herbert Xu
2005-03-25 5:52 ` Evgeniy Polyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1111665551.23532.90.camel@uganda \
--to=johnpol@2ka.mipt.ru \
--cc=akpm@osdl.org \
--cc=cryptoapi@lists.logix.cz \
--cc=davidm@snapgear.com \
--cc=herbert@gondor.apana.org.au \
--cc=jgarzik@pobox.com \
--cc=jmorris@redhat.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox