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:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
- From: Evgeniy Polyakov <[email protected]>
- Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
- From: Jeff Garzik <[email protected]>
- Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
- References:
- [PATCH] API for true Random Number Generators to add entropy (2.6.11)
- From: David McCullough <[email protected]>
- [PATCH] API for true Random Number Generators to add entropy (2.6.11)
- Prev by Date: [PATCH 3/3] Keys: Make request-key create an authorisation key [try #2]
- Next by Date: Re: [Bug] invalid mac address after rebooting (kernel 2.6.11.5)
- Previous by thread: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
- Next by thread: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
- Index(es):